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Strategic  planning  is  receiving  increased  emphasis  in 
both  public  and  private  sector  organizations.   This 
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After  issuance  of  such  a  plan,  organizational  components 
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consonance  with  the  corporate  plan  of  action.   This  thesis 
analyzes  the  existing  and  planned  Stock  Point  Logistics 
Integrated  Communications  (SPLICE)  Project  initiatives  in 
light  of  the  NAVSUP  Strategic  Plan.   The  results  of  these 
analyzes  are  recommendations  which  will  bring  the  SPLICE 
Project  application,  external  system  interface,  and  system 
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I.   INTRODUCTION 

A.  THE  PURPOSE 

Tne  purpose  of  this  thesis  is  to  assist  the  Naval  Supply 
Systems  Command  (NAVSUP)  Stock  Point  Logistics  Integrated 
Communications  Environment  (SPLICE)  project  office,  SUP 
0472,  in  accomplishing  the  task  of  strategic  and,  to  a 
limited  extent,  tactical  project  planning.   As  a  result  of 
this  effort,  a  long  range  SPLICE  project  planning  guide  vn' 1  1 
emerg  e . 

B.  THE  PLANNING  PROBLEM 

Since  this  thesis  will  address  project  planning,  the 
immediate  problem  becomes:  upon  what  should  SPLICE  project 
planning  be  based  within  NAVSUP?   Once  this  question  is 
answered,  the  follow-on  problem  of  what  changes  must  be  made 
to  the  existing  SPLICE  project  plans  will  be  addressed,  in 
light  of  the  answer . 

C.  METHODOLOGY 

A  key  element  that  appears  to  differentiate  well  managed 
organizations  from  average  or  mediocre  organizations  is  the 
degree,  levels,  and  cohesiveness  of  planning  used  by 
management.   Thompson  and  Strickland  [Ref.  1]  support  this 
position.   Their  research  leads  them  to  claim  that  managers 
in  more  successful  organizations  make  time  to  formulate  a 
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systematic  blueprint  of  management's  answers  to  three 
critical  questions: 

1.  What  does  the  organization  do  and  for  whom? 

2.  What  objectives  does  the  organization  want  to 
achieve,  over  what  period  of  time,  and  how  are  these 
objectives  measured? 

3.  How  must  the  organization  be  managed  or  changed  to 
achieve  the  objectives  and  measure  performance? 

The  document  which  an  organization  produces  that  contains 

the  answers  to  these  questions  is  its  strategic  plan. 

At  the  highest  levels  of  management,  a  strategic  plan 

may  be  referred  to  as  a  corporate  plan.   To  have  any  degree 

of  impact  on  an  organization,  a  strategic  plan  must  be 

embraced  by  all  levels  of  management  and  translated  into 

associated  lower  level  plans  of  action  or  strategies  with 

stated  measurable  objectives.   At  middle  management  levels, 

the  implementation  strategies  and  objectives  to  achieve  the 

corporate  goals  are  called  business  plans  or  functional  area 

plans.    In  terms  of  automated  data  processing  (ADP) 

systems,  the  applicable  functional  area  plan  is  often 

referred  to  as  the  Management  Information  Systems  Plan  and 

its  corresponding  architecture  [Ref.  2].   At  the  lowest 

levels  of  management,  operational,  tactical,  or  project 

plans  provide  "the  nuts  and  bolts"  of  how  the  business  or 

functional  area  plans  will  be  carried  out.   Success  or 

failure  of  the  corporate  plan  depends  heavily  on  how  well 

the  lower  level  plans  fit  or  are  made  to  fit  the  corporate 

strategy,  how  performance  is  measured,  and  how  corrective 
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action  is  applied  to  lower  level  plans  for  deviations  from 
the  corporate  plan. 

The  Thompson  and  Strickland  model  of  basing  operational, 
tactical,  or  project  plans  on  corporate  and  functional  area 
plans  will  be  the  methodology  used  within  this  thesis  for 
proposing  modifications  to  SPLICE  project  plans. 


D.   THE  NAVSUP  STRATEGIC  PLAN 

The  trend  found  in  the  more  successful  organizations  to 
perform  formal  corporate  planning  has  not  gone  unnoticed  in 
the  public  sector.   Of  particular  importance  to  this  thesis 
was  the  decision  by  NAVSUP  in  1985  to  produce  a  formal 
corporate  plan,  which  was  called  the  NAVSUP  Strategic  Plan 
[Ref.  3]. 

The  NAVSUP  Strategic  Plan  is  the  result  of  over  a  years 
worth  of  effort  by  headquarters  top  management  personnel  in 
mapping  where  the  "corporation"  is  and  where  it  should  be 
going.   It  essentially  replaces  previous  NAVSUP  strategy  and 
planning  tools,  such  as  the  "Key  Indictor"  program  and  the 
"Top  Concerns"  lists.   An  indication  of  the  seriousness  of 
this  planning  effort  comes  from  the  fact  that  during  a  three 
month  period  within  this  year,  virtually  all  Division 
Directors  and/or^  Deputies  at  the  headquarters  were 
sequestered  to  an  off  site  location  (from  NAVSUP)  to  permit 
undivided  attention  to  the  development  of  this  plan. 
Subsequent  actions  taken  in  support  of  this  plan  included 
numerous  area  specific  steering  committee  meetings  and  a 
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reorganization  of  some  directorates  at  NAVSUP  itself  in 
order  to  better  implement  the  plan. 

The  NAVSUP  Strategic  Plan  restructured  the  three  basic 
questions  posed  by  Thompson  and  Strickland  into  the 
following  four  questions: 

1 .  What  is  our  j  ob? 

2 .  Who  are  we? 

3.  Where  are  we  going? 

4 .  How  do  we  get  there? 

The  plan  answers  the  first  question  in  terms  of 
reiterating  the  NAVSUP  mission,  including  its  scope  and 
responsibilities.   The  second  question  is  answered  in  terms 
of  defining  the  internal  and  external  environment  NAVSUP 
faces.   The  environment  is  described  in  terms  of  a  detailed 
corporate  profile  and  a  listing  of  laws,  regulations  and 
policy  directions  with  which  it  must  coexist.   The  third 
question  was  answered  by  defining  nine  critical  success 
factors  with  related  goals.   In  the   context  of  this  plan, 
goals  appear  as  long  term  results  that  NAVSUP  wishes  to 
achieve.   The  final  question  was  answered  in  terms  of 
stating  78  opportunities,  65  assumptions,  38  strategies,  and 
125  objectives.   Opportunities  appear  as  situations  which 
may  be  developed  or  capitalized  upon  for  the  advancement  of 
the  organization.   Assumptions  are  statements  about  the 
anticipated  future  position  of  the  organization.   Strategies 
appear  as  means  to  accomplish  goals  by  providing  corporate 
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direction  and  intent.   Objectives  appear  as  immediate,  short 
run  actions  which  implement  strategies  and  which  should  be 
supported  by  tactical  initiatives.   Objectives  are  measured 
through  estimated  completion  dates  only. 


E.   THE  NAVSUP  STRATEGIC  INFORMATION  SYSTEM  PLAN 

The  task  of  developing  an  Information  Systems  Plan  which 
supports  the  Strategic  Plan  fell  under  the  purview  of  the 
NAVSUP  Deputy  Commander  for  Inventory  and  Information 
Systems  Development  (SUP  04).   SUP  04  directed  the  creation 
of  an  Information  Systems  Steering  Committee  and  Planning 
Team  with  representatives  from  each  SUP  04  division  to 
develop  the  NAVSUP  Strategic  Information  Systems  Plan. 
Using  the  format  of  the  NAVSUP  Strategic  Plan,  the  same  four 
basic  questions  were  answered,  but  the  answers  were  tailored 
to  the  specific  mission  area  of  SUP  04.   The  definitions  of 
goals,  opportunities,  assumptions,  strategies,  and 
objectives  appear  consistent  with  those  used  in  the  NAVSUP 
Strategic  Plan.   The  result  of  this  effort  was  the  approved 
NAVSUP  Strategic  Information  Plan  of  12  June  1985  [Ref.  4]. 

Using  the  Thompson  and  Strickland  model,  the  SPLICE 
project,  which  falls  under  SUP  04,  should  base  its  project 
plans  upon  the  new  NAVSUP  Strategic  Information  System  Plan, 
which  itself  is  based  upon  the  NAVSUP  Strategic  Plan.   It  is 
appropriate,  therefore,  to  examine  the  NAVSUP  Strategic 
Information  Systems  Plan  prior  to  discussing  specific  SPLICE 
project  plans  or  changes  to  them. 
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The  seven  goals  listed  in  the  NAVSUP  Strategic 
Information  System  Plan  are  directly  related  to  eight  of  the 
nine  critical  success  factors  and  associated  goals  listed  in 
the  NAVSUP  Strategic  Plan.   These  goals  are: 

1.  Assure  that  the  Material  Requirements  Determination 
Program  fully  supports  fleet  and  weapons  system 
logistics  support  requirements. 

2.  Establish  and  administer  an  effective  NAVSUP 
Information  Resources  Management  Program  including 
data  administration,  so  that  information  is  managed  as 
a  resource . 

3.  Assure  that  on-going  and  future  information  system 
initiatives  provide  security,  data  accuracy,  maximum 
integration,  and  timely  return  on  investment. 

4.  Assure  that  NAVSUP  information  system  modernization 
efforts  result  in  improved  user  effectiveness, 
increased  productivity,  and  Detter  use  of  Navy 
resources . 

5.  Obtain  and  retain  qualified  personnel  including 
functional  specialists  who  can  articulate  user 
requirements  in  the  system  design  process. 

6.  Ensure  SUP  04  develops  and  maintains  comprehensive 
strategic  and  tactical  plans,  performs  effective 
budgeting,  and  efficiently  manages  its  corporate 
assets  consistent  with  the  overall  NAVSUP  mission  and 
goals. 

7.  Assure  that  NAVSUP  effectively  exploits  new  and 
emerging  information  system  technology. 

Of  these  seven  goals,  all  but  number  five  are  seen  as 

directly  impacted  by  the  SPLICE  project.   SPLICE  can  also 

support  number  five  indirectly  through  the  applications 

which  utilize  it. 

The  heart  of  NAVSUP  Strategic  Information  System  Plan 

lies  in  the  Opportunities,  Assumptions,  Strategies  and 

Objectives  portions  of  the  plan.   These  documents  are 
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reproduced,  in  part,  as  appendices  A  through  D-1   Since  the 
information  contained  in  these  four  documents  is  so  critical 
to  lower  level  planning  efforts,  interpretation  of  some 
statements  contained  therein  is  necessary. 

First,  the  identified  opportunity  area  will  be 
addressed.   Sixty-three  opportunities  were  developed  by  the 
Steering  Committee.   These  opportunities  "identified 
programmatic  and  technical  options  available  to  SUP  04  to 
improve  operations  and  information  systems  effectiveness" 
[Ref.  5].   Of  these  63  opportunities,  28  are  seen  as 
applicable  to  SPLICE  and  assumed  operative.   These  28 
opportunities  are  identified  in  Appendix  A  by  an  asterisk 
(*)  positioned  next  to  the  opportunity  number.   Three  of 
these  28  opportunities  require  further  qualification  in 
terms  of  this  document. 

Opportunity  number  18  refers  to  the  incorporation  of 
common  data  elements  in  an  "integrated  data  base 
environment"  which  is  to  serve  Inventory  Control  Points, 
Stock  Points,  Headquarters  System  Commands,  and  other  ashore 


^Although  the  NAVSUP  Strategic  Information  Systems  Plan 
critical  success  factors  and  associated  goals  are 
specifically  cross-referenced  to  the  NAVSUP  Strategic  Plan, 
the  follow-on  opportunities,  assumptions,  strategies,  and 
objectives  are  not  in  all  cases  (in  the  version  held  by  the 
authors).   The  authors  assume  that  all  the  NAVSUP  Strategic 
Information  Systems  Plan  opportunities,  assumptions, 
strategies,  and  objectives  completely  and  correctly 
correspond  to  those  of  the  senior  level  plan,  particularly 
those  which  indicate  SUP  04  lead  or  assist  responsibility. 
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and  afloat  units.   The  purpose  of  this  is  to  reduce  data 
redundancy  and  promote  sharing,  accessibility,  and  accuracy. 

This  opportunity  implies  that  when  geographically 
distinct  system  users  or  applications  require  use  of  common 
data,  rather  than  store  it  locally  (i.e.,  redundantly)  the 
user  or  application  should  be  able  to  access  a  centralized 
data  storage  facility  to  obtain  that  data,  in  real-time. 
Data  so  provided  would  be  used  in  subsequent  local 
processing. 

Martin  [Ref.  6]  directly  addresses  this  situation  and 
states  that  commercially  available  data  base  management 
software  is  designed  to  work  in  a  single  computer 
environment  or  in  a  basically  homogeneous  computer  complex. 
Few  cooperative  or  even  multiple  vendor  hardware  (i.e., 
non-IBM  compatible)  data  base  management  systems  exist,  the 
notable  exception  being  ORACLE.   No  mul t i -vendor  , 
integrated,  distributed,  and  real-time  database  management 
system  currently  exists  which  supports  all  logistics  system 
hardware  suites.   This  fact  will  severely  curtail  efforts  to 
reduce  data  redundancy. 

With  the  wide  divergence  among  hardware  and  software 
used  by  the  logistics  user  community,  their  geographical 
dispersion,  and  their  local  operational  system  response  time 
requirements,  the  creation  of  an  "integrated  data  base 
environment"  to  achieve  reduced  data  redundancy  throughout 
the  logistics  system  as  implied  in  opportunity  number  18 
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appears  overly  ambitious.   With  the  hardware  and  software 
suits  available,  it  may  be  possible  to: 

1.  define  and  implement  common  data  element  definitions 
within  a  multitude  of  data  dictionary/data  directory 
systems; 

2.  and  provide  interoperability  among  the  various  users 
for  access  to  individual  data  bases. 

However,  the  use  of  common  logistics  data  elements  in  an 

integrated,  cooperative,  and  distributed  data  base 

environment  across  all  logistics  systems  users  without 

redundancy  and  meeting  short  response  times  does  not  appear 

technically  or  operationally  feasible  for  the  foreseeable 

future . 

This  document  assumes  that  the  opportunity  for  reduction 
in  data  redundancy  is  limited  to  individual  NAVSUP 
collocated  data  bases,  with  incompatible  or  non-contiguous 
systems  using  redundant  data,  where  necessary  to  meet  real- 
time response  requirements. 

Opportunity  number  23  describes  the  promotion  of 
competition  in  future  information  system  resource 
acquisitions  through  the  use  of  portable  and  machine 
independent  application  programs.   This  opportunity  must  be 
interpreted  from  two  aspects. 

First,  since  most  data  base  management  systems, 
transaction  processing  monitors,  and  fourth  generation 
languages  are  not  portable,  applications  which  use  these 
facilities  will  be  machine,  or  compatible  hardware 
dependent.   This  will  be  particularly  true  for  applications 
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which  are  re-written  in  fourth  generation  languages  or 
application  generators  which  take  advantage  of  the 
productivity  gains  available  to  systems  developers  using 
such  f ac  i  1  i  t  i  es . 2 

Secondly,  opportunity  23  appears  to  be  of  lesser 
importance  in  light  of  opportunity  37,  which  indicates  that 
opportunities  exist  for  long  term  single  vendor 
relationships.   If  such  long  term  relationships  are 
available  and  desirable,  why  worry  about  portability  for  new 
information  resource  acquisitions  during  the  less  than  six 
year  window  of  this  plan?   Are  current,  near  term,  or  future 
NAVSUP  applications  intended  for  life  cycles  in  excess  of 
the  current  15  to  24  year  vendor  hardware  contracts?   Should 
NAVSUP  be  planning  now  to  port  third  or  fourth  generation 
applications  to  the  fifth  or  sixth  generation  machines  that 
will  be  available  at  the  end  of  these  long  term  single 
vendor  relationships? 

In  light  of  these  comments  and  for  purposes  of  this 
document,  opportunity  number  23  will  be  assumed  to  apply 
solely  to  the  functional  area  logic  of  existing  and  new 
COBOL  applications.   All  data  base  access  and  usage  code, 
transaction  monitors,  screen  facilities,  and  fourth 
generation  language  code  will  be  assumed  to  be  non-portable 
and  d  i  sposabl e  . 


^See  Appendix  B,  assumption  numbers  21  and  45 
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The  final  comment  on  opportunities  addresses  opportunity 
number  37,  which  discusses  hardware  and  software  contractual 
vehicles  providing  both  technological  refreshment  and  long 
term  single  vendor  relationships.   The  former  part  of  tnis 
opportunity  poses  no  problem  to  the  authors.   The  latter 
part  stating  the  desire  for  long-term  single  vendor 
relationships  does  require  interpretation. 

This  opportunity  seems  to  exist  in  spite  of  the 
increased  emphasis  within  NAVSUP  on  competition  and 
procurement  system  breakouts, 3   Although  there  are  well 
documented  advantages  to  having  a  solid,  long  term 
relationship  with  a  single  hardware  and  software  vendor, 
there  are  Navy  and  non-Navy  ADP  oversight  organizations  and 
committees  that  rank  potential  price  and  performance 
advantages  in  periodically  recompeting  all  or  portions  of 
the  hardware  and  software  environment  higher  than  the 
potential  advantages  gained  through  long  term  single  vendor 
use.   If  required  to  periodically  compete  "portions"  of 
long-term  contractual  vehicles,  this  may  well  mean 
multi-vendor  support. 

For  purposes  of  this  document,  long  term  single  vendor 
relationships  will  be  considered  preferable,  but  both 
contractual  and  physical  facilities  for  integrating  hardware 
and  software  from  multiple  vendors  must  always  be  available 
within  procurement  vehicles.   Each  technological  refreshment 


^NAVSUP  Strategic  Plan  strategy  number  29  applies 
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planned  must  be  "scrubbed"  for  price  and  performance 
advantages  in  the  marketplace.   This  opportunity  is  further 
interpreted  to  mean  that  government  controlled  integrating 
facilities  will  be  available  and  used,  if  and  when  price  or 
performance  advantages  can  accrue  to  the  government  that 
will  not  be  matched  by  existing  single  vendor  contracts. 

Moving  to  the  area  of  assumptions,  of  the  45  listed  in 
Appendix  B,  all  but  three  are  applicable  to  SPLICE  and 
assumed  applicable.   Applicable  assumptions  are  marked  with 
an  asterisk  by  the  assumption  number.   Three  of  these 
assumptions  require  interpretation. 

Assumption  number  14  states  that  off-the-shelf  data  base 
management  systems  and  automated  data  dictionaries  will  be 
used  in  all  major  systems.   For  the  purposes  of  this 
document,  this  is  interpreted  to  include  existing  systems 
which  only  have  minimal  or  no  real  data  base  management 
facilities  (e.g.,  file  systems  such  as  the  Terminal 
Application  Processing  System  (TAPS)4  n  on  TANDEM)  or  with 
passive  data  dictionaries  (e.g.,  TANDEM  Data  Definition 
Language).   This  assumption  will  further  be  interpreted  to 
mean  that  no  in-house  actions  will  be  undertaken  for 
development  of  facilities  of  a  similar  nature. 

Assumption  number  20  is  an  elaboration  on  opportunity 
number  37,  concerning  the  single  vendor  concept.   For 


^TAPS  is  a  product  of  Informatics  General  Corporation. 
It  has  facilities  for  application  management,  communications 
management,  and  data  or  file  management. 
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purposes  of  this  document,  the  comments  made  on  opportunity 
number  37  also  apply. 

Assumption  number  21  refers  to  the  increased  use  of 
"high  level"  programming  languages  for  ad  hoc  reports, 
queries,  and  the  increased  use  of  application  generators  in 
developing  new  systems.   "High  level"  languages  normally 
refer  to  third  generation  procedural  languages  such  as 
COBOL,  FORTRAN,  or  PL/1  [Ref.  7].   This  document  interprets 
this  assumption  to  refer  instead  to  fourth  generation 
non- proc ed ur al  and  interactive  query  languages. 

Of  the  27  strategies  listed  in  Appendix  C,  18  are 
applicable  to  SPLICE,  and  are  so  indicated  with  an 
asterisks.   Two  comments  on  this  section  are  necessary. 
First,  strategy  number  13  regarding  portable  and  machine 
independent  application  programs  is  duplicative  of 
opportunity  number  23,  which  was  discussed  previously.   If 
this  duplication  is  not  by  design,  one  or  the  other  should 
be  eliminated.   Second,  the  comments  made  to  opportunity 
number  23  also  apply  to  strategy  number  13. 

Ninety-eight  objectives  are  stated  in  the  plan  and 
summarized  in  Appendix  D.   Of  these,  41  are  directly 
applicable  to  SPLICE  and  are  so  indicated  with  an  asterisk 
next  to  the  objective  number.   No  objectives  applicable  to 
this  thesis  require  interpretation. 
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F.   SPLICE  PROJECT  PLANNING 

With  the  NAVSUP  Strategic  Information  Systems  Plan  in 
place  along  with  the  authors'  interpretations,  the  next  step 
will  be  an  analysis  of  the  SPLICE  project  in  light  of  this 
plan.   The  path  the  authors  will  take  to  accomplish  this 
effort  is  as  follows.   Following  a  presentation  of  the 
background  of  the  SPLICE  project,  a  "strawman"  set  of  new 
project  goals,  strategies  and  objectives  will  be  proposed. 
These  will  be  based  upon  the  NAVSUP  Strategic  Information 
System  Plan  outlined  above  and  the  capabilities  present  in 
SPLICE  itself  as  outlined  in  the  background  chapter.   Then, 
each  existing  or  potential  SPLICE  project  implementation  or 
application  area  will  be: 

1.  analyzed  in  terms  of  its  intended  purpose  and 
benefits  to  the  corporation; 

2.  analyzed  in  terms  of  migration  need  and  potential  to 
the  Stock  Point  ADP  Replacement  (SPAR)  Project; 

3.  summarized  in  terms  of  how  it  tactically  supports  or 
can  better  support  proposed  SPLICE  objectives, 
thereby  supporting  previously  proposed  project  goals 
and  strateg  ies . 

The  result  of  this  effort  will  be  an  integrated  set  of 

SPLICE  project  goals,  strategies,  and  objectives  that,  along 

with  recommended  changes  to  tactical  initiatives,  will 

reorient  the  project  to  be  more  in  line  with  the  NAVSUP 

Strategic  Information  Systems  Plan,  where  divergence  is 

encountered  or  where  project  capabilities  can  be  used  to 

accomplish  previously  unanticipated  corporate  objectives. 
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With  this  plan  of  action  in  mind,  the  SPLICE  project 
background  is  next  presented. 
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II.   BACKGROUND 

A.   CHAPTER  OVERVIEW 

The  SPLICE  project,  as  it  exists  today,  represents  an 
evolutionary  growth  of  on-line,  distributed  processing  and 
telecommunications  support  within  the  NAVSUP  data  processing 
environment.   At  its  inception  as  a  joint  NAVSUP  and  Navy 
Fleet  Material  Support  Office  (FMSO)  effort,  SPLICE'S  scope 
was  merely  to  lessen  the  impact  of  capacity  and  local 
telecommunications  problems  associated  with  the  stock  point 
Burroughs  medium  systems.   It  was  also  to  provide  a  standard 
local  interactive  processing  capability  and  augment  and 
replace  existing  Burroughs  remote  job  entry  (RJE)  equipment 
[Ref.  8].   In  contrast,  SPLICE  today  has  grown  to  encompass: 

1.  local  high  speed  inter-computer  communications  for 
process- to- process  interface,  multi-host  access  from  a 
single  terminal,  and  peripheral  resource  sharing; 

2.  a  base  from  which  to  develop  and  deploy  new 
local  and  network  oriented  applications; 

3.  fault-tolerant  application  processing; 

4.  a  medium  to  share  Burroughs  resident  master  files  with 
or  without  directly  accessing  the  Burroughs  hosts; 

5.  the  NAVSUP  communications  system  backbone  including  an 
interface  to  the  Defense  Data  Network  (DDN)  and  non- 
DDN  based  heterogeneous  system  connectivity  for 
interoperability,  horizontally  and  vertically 
throughout  the  logistics  system; 

6.  a  vehicle  to  permit  the  use,  replacement,  or 
interface  of  multiple  vendors'  ADP  hardware 
throughout  the  Navy  logistics  system; 
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7.  a  means  of  providing  interim  office  automation,  local 
area  network,  and  management  productivity  tools  to  the 
stock  points. 

8.  and  a  bridge  for  transition  to  the  modern  mainframe 
computers  to  be  acquired  by  the  SPAR  Project. 

The  key  features  of  SPLICE  which  have  permitted  the 

implementation  of  these  divergent  capabilities  are: 

1.  A  highly  flexible  and  comprehensive  contact  for 
hardware,  software,  maintenance,  training, 
documentation,  and  vendor  support  [Refs.  9  and  10], 
which  includes  technological  refreshment  capabilities; 

2.  A  very  responsive  prime  contractor,  Federal 
Corporation  (FDC),  who  has  taken  great  pains  to 
understand  the  breath  and  potential  of  the  SPLICE 
project  and  has  provided  supplemental  environmental 
software  training,  designs,  and  implementations 
which  enhance  the  open  architecture  and  processing 
capabilities  of  the  project  (e.g.,  SPLICENet  [Ref. 

11]); 

3.  A  small,  yet  technically  oriented  project  staff  at 
both  NAVSUP  and  FMSO,  who  have  firmly  guided  the 
project  to  achieve  its  stated  objectives; 

4.  A  dedicated  and  well  trained  software  staff  at  the 
NAVSUP  Central  Design  Agency  (CDA),  FMSO,  who  are 
taking  full  advantage  of  the  power,  modularity,  and 
flexibility  of  the  SPLICE  hardware  and  software 
provided  in  the  contract. 

In  order  to  fully  appreciate  the  role  that  SPLICE  can 

play  in  fulfilling  the  goals,  strategies,  and  objectives  of 

both  the  NAVSUP  Strategic  and  Strategic  Information  System 

plans,  it  is  necessary  to  follow  the  growth  in  scope  and 

capabilities  of  this  project.   The  ability  of  the  project  to 

accommodate  change  and  this  growth  in  the  past  demonstrates 

the  projects's  flexibility  and  versatility  in  meeting  the 

ever  changing  demands  of  the  NAVSUP  environment  and  serves 

as  an  indication  of  its  ability  to  meet  future  corporate 
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needs.  The  following  paragraphs  fulfill  this  role, 
highlighting  the  above  mentioned  key  features  where 
appropriate. 

B.   EARLY  HISTORY 

The  SPLICE  project  began  in  late  1977  as  the  result  of  a 
FMSO  presentations  to  NAVSUP  concerning  remaining 
deficiencies  of  the  Burroughs  medium  systems  in  the  areas  of 
capacity,  local  telecommunications  support,  interactive 
processing  support,  and  RJE  support  [Ref.  12].   These 
deficiencies  require  explanation  to  provide  an  understanding 
of  the  stock  point  environment  and  the  initially  planned 
role  of  SPLICE. 

The  Burroughs  medium  systems,  then  B3500s,  had 
originally  been  competitively  procured  by  NAVSUP  in  the 
early  1970's.   These  systems  replaced  earlier  NAVSUP  Uniform 
Automated  Data  Processing  for  Stock  Point  (UADPS-SP) 
hardware  and  software,  which  were  IBM  1410  based  or  IBM 
360/50  systems  emulating  1410  hardware.   In  that  the  IBM 
1410s  were  primarily  batch  oriented  processors,  the  existing 
applications  which  were  to  be  transitioned  to  the  Burroughs 
hardware  were  primarily  batch  oriented.   Transition  to  the 
Burroughs  hardware  was  to  be  accomplished  with  limited 


^This  presentation  is  called  within  the  project  the 
SPLICE  "Spaghetti  Bowl  Pitch". 
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redesign  or  modernization. 6   This  resulted  in  the  initial 
Burroughs  systems  also  being  primarily  batch  oriented. 
Prior  to  successful  implementation  of  the  transitioned 
UADPS-SP  applications  throughout  the  stock  points,  both 
system  limitations  and  needed  technological  enhancements 
began  to  manifest  them  selves. 7 

The  Burroughs  off-the-shelf  environmental  software  prior 
to  initial  UADPS-SP  implementation  appears  to  have  been 
deficient  in  the  common  services,  audit  trail,  scheduling, 
data  communications,  and  disk  accessing  and  storage  areas. 
Applicable  environniental  software  packages  were,  therefore, 
modified  jointly  through  Burroughs  and  FMSO  to  provide: 

1.  common  services  and  journal ing  facilities  (i.e. 
System  Common  Services  Program  (SCSP)  and  other  copy 
routines),  callable  by  application  programs; 

2.  time/volume  host  scheduling,  terminal  security,  and 
a  line  oriented  teletype  terminal  access  system 
(i.e..  System  Data  Communications  Handler  (SDCH)); 

3.  and  a  more  dense  record  storage  and  efficient  disk 
accessing  capability  (i.e..  Block  Random  Access 
Method/Hierarchical  Access  Method  (BRAM/HAM)). 


^The  UADPS-SP  Mark  I  Autocoder  system  was  converted  to 
COBOL  under  Mark  II.   Other  changes  under  Mark  II  included 
file-level  controls  of  user  data  through  file  naming 
standards,  record-level  user  identification  for 
transactions,  transaction/reconstruct  data,  user  parameters 
via  Systems  Constant  Areas,  and  true  multiprogramming  under 
the  Burroughs  Master  Control  Program. 

''little  written  information  could  be  found  on  the  early 
history  of  the  Burroughs  UADPS-SP  systems.   A  brief  history 
was  located  in  the  FMSO  UADPS-SP  Executive  Handbook.   The 
authors'  summary  is  based  upon  this  and  upon  discussions 
with  various  NAVSUP  and  FMSO  personnel  who  were  present  at 
the  time. 
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These  extensions  to  the  then  commercial  Burroughs  medium 
systems  software,  provided  UADPS-SP  capabilities  which  were 
then  considered  "state-of-the-art"  in  terms  of  data 
processing,  while  also  making  the  software  Navy  unique. 

As  time  progressed  into  the  1970's,  further  enhancements 
were  felt  necessary  in  the  areas  of  RJE  support  (to  further 
permit  remote  sites  to  share  the  processing  capabilities  of 
stock  point  hosts),  increased  terminal  and  Cathode  Ray  Tube 
(CRT)  terminal  support,  and  finally,  more  extensive  on-line 
terminal  capabilities.  Again,  Burroughs  and  FMSO  rose  to 
the  task  and  developed: 

1.  the  Multiple  Activity  Processing  System  (MAPS)  for 
the  Burroughs  hosts  and  the  Satellite  Access  Monitor 
(SAM)  software  for  remote  Burroughs  B1700  RJE 
minicomputers,  replacing  the  earlier  Multiple  File 
Concept/COPE  software; 

2.  modified  SDCH  to  handle  newer  Burroughs  CRT  terminal 
types  and  increased  the  quantities  of  terminals 
available  to  the  system  through  additional  changes 
to  SDCH  and  the  introduction  of  terminal 
concentrators  (i.e.,  TC3800  series)  and  front-end 
data  communications  processors  (FEPs)  (i.e.,  B774); 

3.  and  modified  SDCH  and  copy  routines  to  permit 
application  use  of  Burroughs  block  mode  CRTs  for  on- 
line screen  oriented  applications. 

As  the  UADPS-SP  system  continued  to  mature,  the  FMSO 

environmental  software  engineers,  aided  by  the  Burroughs 

Federal  Systems  Group,  began  to  see  that  additional  changes 

to  the  now  thoroughly  Navy  unique  Burroughs  software,  were 

becoming  more  and  more  complicated,  more  time  consuming, 

more  costly,  and  in  some  cases,  had  reached  the 

architectural  limits  of  the  Burroughs  medium  systems  using 
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the  Navy  unique  software.   Concurrent  with  this  realization, 
NAVSUP  was  obtaining  newer,  more  powerful  Burroughs  hosts, 
remotes,  terminal  concentrators,  and  terminal  hardware  to 
further  relieve  saturation  and  augment  and  further  deploy 
UADPS-SP  (e.g.,  B4800s,  B374s,  BlSOOs,  B867s,  CRTs,  etc.). 

The  final  straws  that  "broke  the  camel's  back"  in  terms 
of  making  system  enhancements  came  in  the  late  1970's  with: 

1.  Burroughs  host  capacity  saturation  with  little 
further  vertical  or  horizonal  expansion  believed 
possi  bl e ; 

2.  the  advent  of  distributed  interactive  processing  on 
minicomputers; 

3.  and  the  obsolescence  of  existing  MAPS  RJE 
proces  sor s . 

The  new  processing  requirements  which  developed  as  a  result 

of  these  three  events  could  simply  not  be  handled  by  the 

existing  systems  or  other  Burroughs  systems  for  which  Navy 

contracts  existed. 

By  the  mid-1970's  the  Burroughs  medium  system  hosts  at 

the  stock  points  were  rapidly  reaching  capacity  saturation 

due  to  a  relatively  constant  5-15%  annual  application  growth 

rate  throughout  the  past  decade.   This  growth  rate  reflected 

enhancements  to  existing  applications,  the  introduction  of 

new  applications,  as  well  as  a  growing  change  in  user 

processing  methodology.   Many  of  these  new  applications  had 

passed  the  stage  of  using  merely  on-line,  block  mode 

processing  and  now  required  interactive  communications  with 

users.   The  only  method  to  even  simulate  interactive 
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processing,  which  was  gaining  increased  use  in  industry,  on 
the  Burroughs  medium  systems  was  to  make  applications  memory 
resident  and  setting  their  job  scheduling  and  execution 
parameters  at  their  minimum  values  (i.e.,  time  0,  volume  1). 
Such  settings  permitted  rather  rapid  execution  of  these 
privileged  applications,  at  the  expense  of  all  other  on-line 
applications  and  batch  processing. 8   This  option  could  only 
be  used  selectively,  due  to  the  virtual  monopolization  of 
system  resources  this  mode  of  processing  required.   Such  use 
could  not  accommodate  the  interactive  needs  of  all  newly 
planned  applications. 

At  the  largest  stock  points,  host  configuration  up- 
grades had  reached  the  top  of  the  line  compatible  Burroughs 
medium  system  model,  the  B4800,9  and  were  already  being  used 
in  dual-processor  configurations.   Therefore,  vertical 
expansion  was  not  believed  possible.   At  that  time  also,  a 
dual  processor  configuration  (referred  to  as  "2-by")  was 
considered  the  maximum  possible  for  processing  efficiency. 10 
Some  horizontal  expansion  could  be  undertaken  (i.e.,  the 


^Simultaneous  on-line  and  batch  processing  at  stock 
point  sites  is  often  accomplished  today  by  splitting  the 
Burroughs  hosts.   On-line  processing  is  accomplished  on  a 
"primary"  processor  with  the  majority  of  batch  processing 
accomplished  on  a  "secondary"  processor.   Both  processors 
share  files. 

^The  introduction  of  the  B4900  in  1984  provided  a  new 
path  of  vertical  expansion  not  previously  anticipated. 

l^In  1984,  the  Burroughs  Federal  Systems  Group  under 
FMSO  direction  also  developed  an  efficient  "3-by"  B4800 
configuration  which  was  deployed  at  NSC  Norfolk. 
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introduction  of  multiple,  independent,  2-by  systems)  where 
conditioned  computer  room  space  was  available  and  where 
sufficiently  large  applications  could  oe  isolated  on  tnese 
separate  systems.   However,  the  practical  implementation  of 
this  approach  was  limited. 

A  further  complicating  factor  was  also  at  play  here. 
NAVSUP  was  beginning  to  face  questions  from  Navy  and  non- 
Navy  oversight  organizations  as  to  why  competition  was  not 
being  used  for  these  UADPS-SP  hardware  enhancements.   Even 
though  the  initial  Burroughs  contract  had  been  competitive 
and  software  compatibility  issues  abounded,  some  of  these 
oversight  organizations  felt  that  continued  granting  of 
Delegation  Procurement  Authority  (DPA)  for  these  follow-on 
sole  source  procurements  and  contract  modifications  to 
Burroughs  was  questionable.   Open  competition  was  strongly 
encouraged.   Therefore,  NAVSUP  was  rapidly  facing  an  "in 
extremis"  position  concerning  capacity,  particularly  with 
the  advent  of  the  requirement  for  interactive  processing, 
and  simultaneously  being  "pushed"  into  open  competition. 

Since  horizontal  and  vertical  expansion  within  the 
Burroughs  hosts  was  effectively  precluded  and  open 
competition  encouraged,  the  logical  step  was  for  NAVSUP  and 
FMSO  to  look  to  moving  additional  growth  and  interactive 
oriented  applications!!  off  the  Burroughs  hosts  entirely  and 


l^Nineteen  application  or  application  support  areas  were 
identified  in  the  supporting  documentation  to  tne  SPLICE 
Automated  Data  Systems  (ADS)  Plan. 
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onto  other  less  restrictive  systems  which  would  require  only 
minimal  Burroughs  interaction.   The  advent  of  the 
minicomputer  provided  the  means  to  accomplish  this. 

The  minicomputer  revolution  brought  the  ability  for  the 
Navy  to  competitively  acquire  numerous,  relatively  cheap 
hardware  suites  from  multiple  vendors,  along  with  software 
that  could  significantly  reduce  application  development 
time.   This  approach  had  already  been  used  by  several  System 
Commands, 12  who  used  FMSO  as  their  CDA  on  a  project  basis, 
and  who  had  obtained  Interdata  (ID)  7/32  minicomputer 
hardware  and  software  for  their  new  projects. 

On  the  positive  side,  this  approach  was  seen  by  NAVSUP 
as  an  interim  solution  to  both  the  capacity  and  interactive 
processing  problems  discussed  above.   On  the  negative  side, 
however,  each  additional  brand  of  minicomputer  obtained 
would  require  access  to  the  rapidly  saturating  Burroughs 
hosts  on  both  a  process  and  terminal  transaction  (e.g., 
pass-through  to  the  Burroughs)  basis.   Additionally,  these 
new  hardware  suites  often  supported  vendor  unique  terminal 
types  and  non-Burroughs  compatible  data  communications 
packages.   The  possibly  of  having  to  uniquely  interface  a 
large  number  of  "foreign  hosts"  to  the  Burroughs  hosts  via 
ever  growing  data  communications  changes  in  SDCH  appeared 


12Examples  are  NAVSEASYSCOM  with  the  TRIDENT  LOGISTICS 
Data  System  (TRIDENT  LDS),  NAVAIRSYSCOM  with  the  Naval  Air 
Logistics  Command  Information  System  (NALCOMIS)  and  the 
Comptroller  of  the  Navy  (NAVCOMPT)  with  the  Integrated 
Disbursing  and  Accounting  systems  (IDA). 
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prohibitive,  regdrdless  of  the  capacity  relief  provided  by 
these  new  minicomputers. 

It  was  at  this  time  in  December  1977  that  the  "Spaghetti 
Bowl"  pitch  was  made  to  NAVSUP  at  FMSO.   This  pitch 
highlighted  the  above  mentioned  problems,  with  particular 
emphasis  on  the  difficultly  involved  in  interfacing  many 
brands  of  minicomputers  to  the  Burroughs.   This  meeting  also 
provided  a  recommendation  for  resolution:  SPLICE. 

It  was  proposed  that  a  SPLICE  project  should  be 
undertaken  to  provide  a  standard  hardware  and  software 
minicomputer  system  for  all  new  UADPS-SP  interactive 
application  systems.   This  standard  system  would  be 
interfaced  via  land  line,  data  communications  to  the 
Burroughs  hosts.   Since  this  system  would  be  used  by  all  new 
NAVSUP  approved  applications  requiring  interactive 
processing,  only  one  additional  minicomputer  data 
communications  (i.e.,  SDCH)  interface  would  be  required. 
The  overhead  which  this  additional  interface  might  cause 
would  be  off-set  by  moving  Burroughs  terminals  and 
downloading  many  of  the  terminal  oriented  SDCH  functions  to 
SPLICE,  providing  some  Burroughs  capacity  relief. 
Additional  capacity  relief  could  also  be  provided  if 
existing  Burroughs  mainframe  applications  would  download 
their  on-line  transaction  edit  and  validation  functions  to 
the  SPLICE  minicomputers.   Finally,  it  was  proposed  that  a 
functionally  equivalent  form  of  MAPS  SAM  software  be  ported 
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to  SPLICE,  and  when  completed,  use  SPLICE  systems  to  solve 
the  obsolescence  problem  of  the  existing  Burroughs  B1700 
MAPS  RJE  processors. 

This  proposal  potentially  resolved  the  majority  of 
NAVSUP's  recognized  saturation,  interactive  processing,  and 
obsolete  equipment  problems,  on  an  interim  basis,  until  the 
follow-on  SPAR  project  could  be  undertaken.   The  only 
remaining  issue  was  for  which  minicomputer  hardware  and 
software  to  solicit.   This,  too,  was  resolved  at  the 
December  meeting.   FMSO's  current  investment  in  ID  7/32 
software  development,  both  application  oriented  (using  TAPS) 
and  environmental  (which  developed  into  TRIDENT  Network 
Control  Processor  (NCP)  and  Integrated  Network  Software 
(INS)  for  Burroughs-ID  access)  essentially  resolved  the 
issue.    SPLICE  would  be  developed  and  deployed  on  ID  7/32 
hardware,  obtained  via  a  brandname  or  equal  procurement. 
FMSO  would  standardize  UADPS-SP  and  related  minicomputer 
application  development  on  this  hardware  using  TAPS  and 
develop  additionally  required  environmental  and  MAPS  RJE 
Burroughs  data  communications  interfaces.   Thus,  any 
minicomputer  application  currently  under  design  or  planned 
by  NAVSUP  and  FMSO  could  be  designed  for  and  developed 
immediately  on  existing  ID  7/32  hardware,  later  transitioned 
to  SPLICE,  and  be  deployed  with  little  or  no  modifications. 

Following  several  contractor  studies  on  the  proposal  and 
a  meeting  with  Naval  Data  Automation  Command  (NAVDAC) 
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representatives  to  discuss  the  initiative,  the  SPLICE 
project  was  formally  announced  on  14  July  1978  [Ref.  13]. 
Then,  NAVSUP  "moved  out  smartly"  to  execute  SPLICE, 
anticipating  a  short  hardware  acquisition  and  software 
development  time  window. 13   Steps  taken  included  assignment 
of  a  NAVSUP  project  officer,  formal  tasking  to  FMSO  for 
further  concept  design  [Ref.  14],  assuming  use  of  ID 
hardware  and  TAPS,  and  the  preparation  of  an  agency 
procurement  request  ( APR) /g ran t i ng  of  DPA  for  the 
acquisition  of  50  ID  7/32  minicomputers  [Ref.  15].   From  all 
indications,  it  appeared  to  NAVSUP  that  SPLICE  would  be 
available  for  deployment  by  mid  1979,  prior  to  completion  of 
tentative  applications. 


C.   PROJECT  EVOLUTION 

By  December  1978,  these  original  SPLICE  plans  fell  under 
close  re- ev al uat ion .   Numerous  factors  necessitated  this: 

1.  Although  significant  price  advantages  were  available 
in  minicomputer  Central  Processing  Units  (CPUs), 
these  advantages  did  not  extend  to  peripherals  such 
as  disks,  tape  drives,  and  printers.   The  need  to 
share  high  cost  peripherals  in  collocated  systems 
was  recognized. 

2.  Many  of  the  peripherals  on  the  Burroughs  hosts 
themselves  required  replacement  and  had  top 
priority.   There  would  be  significant  cost  savings 
if  Burroughs  peripherals  (e.g.,  CRTs)  could  be 
shared,  to  some  extent,  from  SPLICE. 

3.  Advances  in  local  and  long-haul  telecommunications 
were  taking  place  in  industry  and  within  the 


l^The  short  software  development  window  was  not 
concurred  with  by  FMSO. 
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Department  of  Defense  (DOD).   These  included 
advanced  terminal  and  host  protocols,  new  more 
powerful  terminals,  and  AUTODIN  11.14   UADPS-SP, 
even  with  SPLICE  implemented  on  the  ID  7/32s,  could 
not  take  advantage  of  these. 

4.  Land  line  data  communications  among  collocated 
processors  was  relatively  slow  and  appeared  unable 
to  meet  all  the  new  applications  response  time  and 
throughput  requirements.   High  speed  i n ter- c ompu ter 
communications  on  incompatible  systems  was  now 
possible  [Ref.  16]  and,  if  implemented  successfully, 
could  serve  as  a  SPAR  transition  strategy. 

5.  The  ID  7/32s  proved  not  to  be  the  "savior"  as  once 
envisioned.   Memory  limitations  (i.e.,  1  MEG),  lack 
of  system  expandability  to  meet  surge  or 
mobilization  requirements,  and  limitations  on  -the 
number  of  terminals  which  could  be  supported  were 
evidenced  even  in  the  FMSO  development  arena.   These 
limitations,  when  extrapolated  to  operational  sites, 
indicated  an  inability  to  handle  peak  processing 
loads.   Worse  then  that,  hardware  and  software 
reliability  of  these  systems  was  low  and  seen  as 
unable  to  support  "up-time"  requirements  of  the  new 
interactive  and  CRT  oriented  applications. 15 

6.  The  estimated  number  and  sizes  of  planned 
applications  along  with  an  emerging  requirement  to 
expand  the  number  of  MAPS  RJE  sites  could  not  be  met 
with  a  mere  50  ID  7/32  minicomputers. 

The  combined  effect  of  these  factors  lead  the  NAVSUP  and 

FMSO  SPLICE  personnel  to  conclude  that  the  original  plans 

for  SPLICE  would  not  produce  a  system  which  could  meet  the 

needs  of  UADPS-SP  through  even  the  1980s.   It  was  necessary 

for  SPLICE  to  change  to  accommodate  these  new  requirements. 


l^AUTODIN  II  was  subsequently  replaced  by 
SPLICE  support  for  DDN  was  later  required  due 
repl ac  emen t . 


the  DDN 
to  this 


l^The  use  of  "hot"  stand-bys  by  TRIDENT  LDS  and 
processor  upgrades  to  larger  PE  minicomputers  in  other 
applications  temporarily  reduced  the  short-run  impact  of 
these  events,  but  could  not  resolve  them. 
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By  May  of  1979,  NAVSUP  cancelled  the  original  SPLICE 
design  tasking  to  FMSO  in  favor  of  a  competitive  procuremeni: 
for  " faul t- tol er an t"  ,  modular,  expandable,  interactive 
processing,  and  communications  oriented  system  hardware  and 
software,  which  included  an  AUTODIN  II  interface  as  well  as 
a  high  speed  local  computer  network  (LCN).   The  size  of  the 
acquisition  also  increased  from  50  processing  systems  to  "2 
to  6  processor  systems"  per  site,  at  62  sites,  orderable 
totally  on  a  requirements  basis.   In  February  1980,  the 
NAVSUP  request  for  DPA  for  the  ID  7/32s  was  formally 
wi  thdrawn  [ Ref .  17] . 

Although  the  NAVSUP  and  FMSO  SPLICE  project  teams 
attempted  to  recover  from  the  time  loss  incurred  due  to  this 
change  of  direction,  other  environmental  factors  worked 
against  them.   Only  a  brief  summary  of  these  factors  is 
presented  below.   A  complete  documentary  history  of  these  is 
avail  able  in  [Ref.  18] . 

New  requirements  for  ADP  project  management  and  control 
resulted  in  a  lengthy  ADS  Plan  development  cycle  with  an 
equally  long  approval  process.   A  new  APR  had  to  be 
generated,  which  was  challenged  at  the  NAVDAC  level  and 
subsequently  modified  to  cover  the  eventual  replacement  of 
all  MAPS  RJE  equipment  and  Burroughs  B774/874  front-end 
processors.   Funding  profiles  were  dramatically  changed  due 
to  the  additional  hardware  requirements.   A  draft 
competitive  solicitation  document  had  to  be  prepared  as 
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required  by  the  Automated  Data  Processing  Selection  Office 
(ADPSO).   Application  processing  profiles  and  workload  data 
had  to  be  collected  in  support  of  site  sizing  and 
benchmarking  efforts.   In  the  middle  of  all  this,  the 
project  was  required  to  transition  to  Life  Cycle  Management 
(LCM)  control,  resulting  in  further  delays  due  to 
documentation  changes,  reviews,  and  new  approvals. 

The  net  effect  of  all  these  changes  was  a  delay  of  over 
27  months  for  the  SPLICE  project  (to  April  1981),  just  to 
get  a  Source  Selection  Evaluation  Board  established  [Ref. 
19],  so  that  an  active  competitive  procurement  could  be 
undertaken.   The  competitive  procurement  process  itself  took 
an  additional  19  months,  and  finally  resulted  in  the 
contract  with  FDC  for  TANDEM  Non-Stop  TXP  systems,  Network 
Systems  Corporation  HYPERchannel  products,  and  associated 
system  software  and  support  on  17  November  1983. 


D.   SPLICE  DESIGN 

As  might  be  expected  during  the  46  months  from  the 
decision  to  openly  compete  for  SPLICE  to  contract  award 
UADPS-SP  hardware,  the  stock  point  application  mix  to  be 
supported,  the  specific  system  support  requirements,  and  the 
FMSO  environmental  designs  continually  changed.    UADPS-SP 
could  simply  not  wait  for  SPLICE,  and  SPLICE  was  required  to 
accommodate  all  changes. 

New  hardware  continued  to  be  added  to  UADPS-SP  in  an 
attempt  to  overcome  immediate  processing  shortcomings  and 
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project  requirements.   Additional  B4800s  were  added  to  the 
inventory  at  larger  sites  under  an  interim  CPU  upgrade 
project,  replacing  earlier  models  which  were  reallocated  to 
smaller  sites.   Starting  in  1985,  B4900  hosts  were  also 
added,  following  an  18  month  planning  effort.   A  Peripheral 
Replacement  Project  replaced  older  Burroughs  disk,  tape,  and 
printer  units.   This  same  procurement  vehicle  obtained  more 
modern  Burroughs  terminal  concentrators  (i.e.,  CP9400s  and 
CP9500S).   Leases  and  buys  of  B1900  minicomputers  replaced 
older  B1700  and  B1800  systems.   New  Burroughs  and  compatible 
terminals  (e.g.,  MT980  series.  Delta  Datas,  etc.)  and 
printers,  as  well  as  microcomputers  were  added  at  sites  in 
large  numbers.    Many  Perkin-Elmer  (PE)  3200  series  hosts 
replaced  older  ID  7/32  systems.   And  finally,  the  Naval 
Integrated  Storage  and  Retrieval  System  (NISTARS)  project 
had  required  that  an  interface  of  TANDEM  Non-Stop  lis  to  the 
Burroughs  system  be  developed.   SPLICE  now  had  to  also 
accommodate  these  changes. 

All  four  of  the  applications  which  were  to  have  been 
totally  application  resident  on  SPLICE  had  been  developed 
and  deployed  on  other  hardware. 16   jhe  remaining  15 


l^iDA  and  the  Navy  Automated  Documentation  System 
(NAVADS)  were  successfully  developed  and  deployed  on  PE 
hardware  using  TAPS.   The  Automation  of  Procurement  and 
Accounting  Data  Entry  System  (APADE)  had  been  developed  and 
prototyped,  but  was  not  deployed  in  its  PE  form.   The 
Receipt  Improvement  Program  (RIP),  renamed  Application  B 
Enhanced  (ABE),  had  been  successfully  developed  and  deployed 
on  Burroughs  terminal  concentrators  with  some  core  resident 
applications  on  the  Burroughs  hosts. 
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applications  which  SPLICE  was  to  support  on  a  pass-through 
basis  to  Burroughs  or  for  edit  and  validation  purposes  had 
either  been  developed  and  deployed  on  Burroughs  or  ID 
equipment,  deferred  indefinitely,  or    were  c  anc  el  1  ed  .  1- 7 
Although  SPLICE  was  still  required  to  function  as  a  base 
from  which  to  develop  other  new  applications  or  the 
functional  transition  of  any  existing  Burroughs  application 
or  part  thereof,  there  were  now  no  immediate  applications  in 
waiting  for  SPLICE. 

With  the  completed  implementation  of  many  of  the 
original  applications  SPLICE  had  planned  to  support,  there 
appeared  to  be  little  urgency,  from  an  application  point  of 
view,  to  move  existing  terminal  processing  to  SPLICE. 18 
SPLICE  project  personnel  felt,  therefore,  that  system 
support  requirements  should  be  migrated  from  an  emphasis  on 
deployment  and  usage  services  for  the  original  19 
applications  to  an  emphasis  on  generalized  communications 
servicesl9  for  any  application  and  for  projected  stock  point 
terminal  additions.   This  change  in  emphasis  was  pursued  but 


l^Transportation  Operational  Personal  Property  Standard 
System  (TOPS). 

l^The  exception  being  Transaction  Ledger  On  Disk  (TLOD). 

l^These  generalized  communications  requirements 
included:  support  for  every  terminal  type  used  within  the 
NAVSUP  community;  local  computer  network  interfaces  to 
Burroughs,  IBM,  PE,  TANDEM,  and  Univac;  data  communications 
interfaces  to  IBM  hosts;  DDN  interface  for  interoperability; 
inter-SPLICE  networking  capabilities;  and  horizontal  and 
vertical  logistics  system  connectivity,  exclusive  of  DDN. 
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resulted  in  SPLICE  having  to  provide  its  own  initial 
environmental  capacity  off-load  from  the  Burroughs  to  make 
up  for  the  initial  additional  workload  that  the  LCN 
interface  would  add  to  the  Burroughs,  assuming  few  Burroughs 
terminals  from  the  existing  inventory  would  be  moved  to 
SPLICE  on  day  one.   Therefore,  a  plan  was  developed  that 
would  permit  the  off-load  of  the  Burroughs  TRANSRECON 
(journal  facility)  to  SPLICE  using  the  LCN  to  provide 
initial  capacity  relief. 

With  the  journal  facility  available  on  SPLICE,  a  means 
was  now  present  to  replicate  Burroughs  master  files  on 
SPLICE  and  keep  them  current  on-line,  once  initial  file 
loads  were  accomplished.   Assuming  this  facility  was 
available,  new  applications  were  then  identified  [Ref.  20] 
that  could  use  these  replicated  files  on  an  immediate 
inquiry  basis  and  for  ad  hoc  batch  reports,  relieving  up  to 
2  hours  of  processing  time  a  day  on  the  Burroughs  hosts. 20 
The  transitioning  of  Burroughs  End-of-Day  application 
processing  to  SPLICE  also  became  a  possibility,  providing 
the  potential  for  even  further  Burroughs  capacity  relief. 
With  the  potential  for  significant  Burroughs  capacity 


20to  meet  this  requirement,  the  SPLICE  Information 
Center  concept  was  born.   This  Information  Center  capability 
revived  interest  in  moving  other  Burroughs  terminals  to 
SPLICE.   With  this  capability,  a  single  terminal  could 
access  Replicated  Files  on  SPLICE  very  rapidly,  or  use 
"pass-thru"  facilities,  on  SPLICE  to  access  non-replicated 
Burroughs  files  or  programs. 
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paybacks,  this  group  of  "download  projects"  was  then  added 
to  the  SPLICE  requirements  list  [Ref.  21]. 

The  SPLICE  long-term  commitments  to  the  originally 
planned,  four  wholly  resident  applications  also  remained 
intact.   Although  these  applications  had  been  developed  and 
deployed  on  other  hardware,  the  limitations  that  had 
necessitated  SPLICE'S  change  in  direction  in  1979  were 
adversely  effecting  them  now.   These  applications  required  a 
"transparent"  transition  vehicle  to  SPLICE.   This  was  to  be 
accomplished  through  the  porting  of  TAPS  to  SPLICE. 21   one 
addition,  however,  was  added  to  SPLICE  support  requirements 
in  this  arena.   A  text  processing  capability  was  emerging  as 
a  requirement  for  the  under  redesign  APADE  application. 

The  original  FMSO  SPLICE  environmental  designs  remained 
in  a  state  of  flux  by  trying  to  keep  up  with  the  moving 
SPLICE  "target."   As  previously  indicated,  the  original 
designs  for  SPLICE  on  the  ID  7/32  were  abandoned.   The 
competitive  solicitation  process  and  the  six  month  window 
mandated  for  completion  of  initial  SPLICE  capabilities  after 
contract  award  required  that  design  and  development  be 
undertaken  without  specifically  knowing  the  target  hardware 
or  software.   This  was  a  particular  problem  on  the 
environmental  interface  software  side,  as  "hooks"  into  the 
procured  "off-the-shelf"  environmental  software  would  be 


21a  similar  porting  of  TAPS  had  been  accomplished  by  the 
Army  for  the  VIABLE  project. 
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required.   Generic  functional  and  system  designs  were 
developed,  in  a  phased  approach,  and  continually  modified  as 
requirements  changed. 22 

To  accommodate  the  numerous  SPLICE  requirements,  the 
project  was  split  into  phases.   The  phases  of  SPLICE  finally 


solidified  as  follows  [Ref.  22]: 

1.  In  the  first  phase  of  the 
hard  war e/ so f tware  systems 
interactive  processing  for 
either  the  procured  Transa 
(TPS)  or  TAPS.  Selected  U 
to  migrate  to  the  SPLICE  h 
total  processing  support  d 
application,  interactive  r 
sites  and  funding  availabi 
take  place  along  the  local 
terminal  and  LCN  networks, 
possible  reduction  of  tele 
on  the  non-SPLICE  computer 
resources.  A  basic  interf 
be  prov  id  ed  . 


d  ev  el opment ,  SPLICE 
were  to  provide  enhanced 

stock  point  systems  using 
ction  Processing  Systems 
ADPS-SP  applications  were 
ardware  for  partial  or 
epending  on  the 
equirements,  processing 
lity.   Processing  was  to 

SPLICE  mult i -vendor 

thereby  beginning 
communications  workloads 
s  and  permitting  shareable 
ace  to  the  DDN  would  also 


In  the  second  phase  of  SPLICE  implementation  of  RJE 
processing  improvements  were  to  be  developed  on 
SPLICE  nodes  and  made  available  to  the  remote  stock 
point  locations.   Software  enhancements  and  SPLICE 
hardware/software  configurations  were  to  improve  and 
expand  remote  processing  methods. 

The  third  phase  of  the  SPLICE  project  was  to  establish 
a  fully  interoperable  network  capability  under  SPLICE 
using  the  ODN  service  protocols. 23 

In  the  final  and  fourth  phase,  the  LCN  interfaces 
were  to  be  expanded  to  support  other  host  systems 
and  to  provide  the  framework  for  SPAR. 


22During  this  period,  the  SPLICE  Requirements  Statement 
was  modified  twice,  and  the  SPLICE  Functional  Description 
and  System  Specifications  were  each  modified  three  times. 


23This,  along  with  additional 
currently  called  SPLICENet. 


non-DDN  functionality,  is 
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At  the  end  of  these  phases,  a  SPLICE  configuration  would 
provide,  at  a  minimum,  support  of  the  following  stock  point 
ADP  or  telecommunications  functions: 

1.  Conversational  (interactive)  program  support, 
including  text  processing; 

2.  Remote  job  entry  services  (including  remote 
input/output  queue  management); 

3.  Queued  support  of  transaction  input/output 
term  i  nal s  ; 

4.  Operating  system,  process  and  file  Integrity  for 
high  system  availability; 

5.  Non-disruptive  reconfiguration/expansion; 

6.  Location  independent  process-to-process 
commun  icat  ions ; 

7.  Modular  expansion  of  hardware  and  software; 

8.  Local  screen  management  support  for  local  display 
terminals  connected  to  remote  processes; 

9.  User  and  process  routing  in  support  of  a  distributed 
transaction  processing  environment. 


D.   SPLICE  DEVELOPMENT 

Actual  SPLICE  Phase  I  prototype  interface  software 
development  based  on  FMSO  design  documents  began  in  the 
summer  of  1981.   This  prototype  software  was  written  in 
PASCAL24  and  developed  on  a  pair  of  interconnected  PE  3244s 
Its  purpose  was  to  test  design  concepts  and  reduce  the 
learning  curve  when  the  final  target  system  was  identified. 
Similar  efforts  were  undertaken  using  a  R&D  funded 
HYPERchannel  system.   Although  it  had  been  hoped  that 


^^This  language  was  selected  for  portability. 

43 


software    developed    from    these    efforts    would    be    ported    to    the 
final     SPLICE    hardware,     in    the    final     analysis,    it    only    served 
to    assist    in    identifying    problems    and    shaking    out    the 
design.       No    software    was    deployed    from    these    initiatives. 

FfiSO    SPLICE    software    design    and    development    resources 
were    used    extensively    during    this    time    on    the    solicitation 
effort,    particularly    in    the    benchmarking    and    operational 
test    areas.       This    dual     use    of    resources    (development    and 
solicitation)     reduced    the    development    output    of    the    FMSO 
SPLICE    team,    but    resulted    in    an    early    familarity    with    the 
potential    hardware    and    software    and,    thus,    reduced    the 
development    learning    curve. 

It    was    not    until     late    within    the    procurement    process    (in 
June    1983    when    only    two    offerors    remained,    both    proposing 
TANDEM    and    HYPERchannel     products)     that    TANDEM    based    SPLICE 
development    commenced    in    earnest.       The    first    commercial 
TANDEM    training    was    obtained    at    this    point    in    identified 
off-the-shelf    software    products,    to    further    reduce 
environmental     and    application    development    lead    time    once    the 
contract    was    awarded.       Following    training,    live    development 
work    began    on    the    SPLICE    environment    software    (i.e.. 
Burroughs    Pre-Processor,    the    File    Replication    software,    and 
the    Navy    interfaces    to    HYPERchannel). 

Since    TANDEM    did    not    corporately    support    PASCAL    at    that 
time,    two    contractual     software    development    efforts    were 
required.       The    first    was    undertaken    to    develop    a    TANDEM 
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based  PASCAL  compiler,  so  that  TAPS,  recently  re-written  in 
PASCAL  on  a  PRIME  host  and  renamed  TAPS  II,  could  be  ported 
to  the  new  hardware  in  order  to  reduce  the  transition  time 
of  two  of  the  four  original  SPLICE  resident  applications 
[Ref.  23].   Additionally,  contractual  efforts  for  the 
porting  of  TAPS  II  itself  to  SPLICE  were  completed  [Ref. 
24]  . 

When  the  SPLICE  acquisition  contact  was  signed  in 
November  1983,  SPLICE  Phase  I  development  was  in  full 
production  mode  on  the  environment  side  and  in  training  mode 
on  the  application  side.   FDC  entered  the  picture  at  this 
point,  providing  on-site  FMSO  support,  additional  training, 
and  completing  their  Security  Access  System  (SAS),  System 
Monitor  (SMON),  and  universal  term inal / pr i n ter  interface 
mapping  (TMAP)  software.    When  the  Burroughs  HYPERchannel 
software  package  (i.e..  Burroughs  NETEX)  provided  from  the 
contract  failed  to  perform  in  an  operational  environment, 
FDC  also  provided  assistance  to  FMSO  in  development  of  a 
local  TANDEM-to-Burroughs  (TABU)  HYPERchannel  software 
package.   Similar  FDC  assistance  was  provided  to  the  initial 
SPLICE  developing  applications:  Transaction  Ledger  on  Disk 
and  Replicated  File  Inquiries. 25   Concurrently,  contractor 
development  was  underway  on  the  Inventory  Location  Audit 
Program  application. 


25These  applications  used  the  TANDEM  native  mode 
transaction  processing  system,  PATHWAY.   TAPS  was  reserved 
solely  for  the  transition  of  IDA  and  NAVADS. 
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All  development  work  for  the  Phase  I  SPLICE  prototype 
site,  Naval  Regional  Data  Automation  Command  (NARDAC) 
Jacksonville,  supporting  Naval  Supply  Center  (NSC) 
Jacksonville,  was  completed  in  the  late  summer  of  1984. 
Implementation  of  Phase  I  of  SPLICE  at  this  site,  including 
the  initial  applications,  was  completed  on  2  November  1984. 
This  successful  prototype  permitted  the  SPLICE  project  to 
submit  their  System  Decision  Paper  III  (SDP  III)  document 
for  system  approval  and  thus  receive  authority  for 
subsequent  system  deployment,  including  follow-on 
development  phases,  capabilities,  and  additional 
applications  [Ref.  25]. 

The  SPLICE  project  is  in  the  process  of  implementing 
Phase  I  throughout  the  stock  point  community.   Concurrently, 
work  is  underway  for  subsequent  phases  and  applications. 
From  this  rather  lengthy  background  chapter,  it  should  be 
clear  that  the  SPLICE  project  has  grown  significantly  over 
the  years  in  both  size  and  potential  to  meet  the  ever 
changing  needs  of  the  NAVSUP  stock  point  environment.   With 
this  background  established,  it  is  now  possible  to  see  how 
the  current  and  projected  SPLICE  capabilities  listed  at  the 
beginning  of  this  chapter  can  be  used  to  facilitate  overall 
NAVSUP  corporate  plans,  through  revised  SPLICE  project 
plans. 
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III.   PROPOSED  SPLICE  PROJECT  PLANS 

A.   CHAPTER  OVERVIEW 

In  the  introduction  to  this  document,  definitions  were 
provided  for  the  terms  goals,  strategies,  and  objectives. 
For  emphasis  purposes,  they  are  reproduced  here: 

1.  Goals  -  long  terms  results  that  an  organization  wishes 
to  ac  h  i  eve  . 

2.  Strategies  -  means  to  accomplish  goals  by  providing 
corporate  direction  and  intent. 

3.  Objectives  -  immediate  short  run  actions  which 
implement  strategies  and  which  should  be  supported  by 
tactical  initiatives. 

How  these  terms  apply  to  SPLICE  planning  is  the  next  area 

which  will  be  discussed. 

The  SPLICE  SDP  III  document  is  the  current  published 

source  of  SPLICE  project  plans.   Its  orientation  and  format 

is  dictated  by  LCM  guidelines  [Ref.  26].   Since  the  SPLICE 

SDP  III  documentation  pre-dates  both  the  NAVSUP  Strategic 

and  Strategic  Information  System  plans,  its  format  is  not 

directly  comparable  to  the  latter  documents.   For  example, 

the  SPLICE  SDP  III  document  uses  a  hierarchy  of  concepts, 

capabilities,  and  what  are  called  "objectives"  to  describe 

what  are  termed  goals  and  strategies  in  the  latter  plans, 

and  uses  Plans  of  Action  and  Milestones  (POA&Ms)  to  describe 

both  other  immediate  objectives,  similar  to  those  in  the 

latter  plans,  as  well  as  tactical  plans. 
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Prior  to  proposing  changes  to  SPLICE  plans  to  bring  them 
into  consonance  with  the  NAVSUP  Strategic  and  Strategic 
Information  System  plans  and  terminology,  it  is  appropriate 
to  present  the  existing  project  plans  for  comparison  and 
analysis  purposes.   To  accomplish  this  a  reorganization  and 
interpretation  of  some  information  in  the  SPLICE  SDP  III 
document  is  required,  particularly  in  the  area  of 
terminology.   The  following  paragraphs  will  provide  the 
basis  for  this  and  then  propose  revisions. 


B.   PROPOSED  SPLICE  PROJECT  GOALS 

The  goals  of  the  SPLICE  project,  termed  key  objectives 
in  the  SPLICE  SDP  III,  are  promulgated  as  follows  [Ref.  27]: 

1.  Provide  a  nucleus  for  supporting  all  current  and 
future  logistics  data  communications  requirements  by 
consolidating  local  and  long  distance  communications 
into  a  single  integrated  network  using  the  DDN  as  a 
backbone; 

2.  Provide  state-of-the-art  interactive  transaction  and 
distributed  processing  capabilities  to  alleviate  the 
saturation  of  the  installed  computer  base; 

3.  Provide  economic  system  support  and  standardization  of 
computer  suites  by  providing  a  general  purpose 
computer  system  to  curtail  the  proliferation  of 
incompatible  minicomputers  at  UADPS-SP  host  and  remote 
sites. 

In  comparing  these  goals  with  those  of  the  NAVSUP 

Strategic  Information  Systems  Plan  presented  earlier  in  this 

document,  one  major  difference  becomes  apparent.   The 

existing  SPLICE  goals  tend  to  deal  more  with  specific  stock 

point  environmental  ADP  issues  than  long  term  logistics 

system  results  or  benefits  that  could  accrue  to  the  NAVSUP 
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corporation  as  a  whole.   This  is  not,  in  and  of  itself,  a 
problem  in  that  the  SPLICE  document  preceded  the  other  two, 
but  it  is  now  inconsistent  with  the  format  and  design  of  the 
senior  level  planning  documents.   In  addition,  however,  the 
goals  themselves  appear  as  either  not  accomplishable  or 
backward  looking,  in  the  opinion  of  the  authors.   The 
following  paragraphs  will  elaborate  on  this  contention. 

The  first  goal  appears  not  accomplishable  from  several 
aspects,  if  one  takes  the  word  "all"  literally.   First, 
SPLICE  has  an  impact  only  on  a  portion  of  stock  point 
logistics  data  communications  requirements,  when  one 
includes  the  NAVDAC  supported  stock  points  and  emerging 
NAVCOMPT  financial  stock  point  related  systems.   The  NARDAC 
and  Naval  Data  Automation  Facilities  (NARDAF)  activities, 
though  their  sponsor  NAVDAC,  are  pursuing  their  own  Univac 
UllOO  DDN  interface  [Ref.  28],  their  own  local  networking 
initiatives,  and  have  never  approved  the  SPLICE  LCN 
interface  to  their  Univac  hosts  [Ref.  29].   The  NAVCOMPT 
IDAFIPS  system  also  includes  its  own  DDN  interface  [Ref. 
30],  its  own  interim  host-to-host  networking  initiative 
using  Burroughs  Network  Architecture  [Ref.  31],  and  was 
never  planned  to  interface  to  the  SPLICE  LCN.   Additionally, 
SPLICE  itself  must  support  non-DDN  based  logistic  data 
communications  requirements  for  Defense  Logistics  Agency 
access  and  interface  to  a  separate  NAVSUP  sponsored 
Inventory  Control  Point  (ICP)  local  and  long-haul  data 
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communications    network,     ICPNet    [Ref.    32].       For    these 
reasons,    this    goal    of    SPLICE    providing    the    nucleus    for    "all" 
current    and    future    stock    point    communications    requirements 
appears    to    the    authors    as    not    accomplishable. 

Moving    to    the    second    goal,    it    appears    to    the    authors    as 
backward    looking,    or    describing    already    completed    events. 
Specifically,    this    goal    appears    to    have    been    already 
accomplished    by    two    events,    with    a    third    event    providing    a 
long    term    resolution.       First,    much    of    the    immediate 
saturation    problem    at    the    stock    points    appears    to    have    been 
resolved    by    the    delivery    of    the    Burroughs    B4900s    to    the 
stock    points    [Ref.    33].       Second,    the    signing    of    the    SPLICE 
contract    itself,    with    subsequent    system    deployment,    provided 
the    processing    capabilities    stated    within    this    goal. 
Additionally,    it    is    in    the    already    completed    and    on-going 
deployment    of    SPLICE    resident    applications    that    additional 
potential     short-run    saturation    problems    can    be    avoided.       The 
third    event,    the    SPAR    project    which    will     shortly    be    awarding 
its    own    long-term    hardware    and    software    contract    for    the 
stock    points,    is    itself    predicated      on    long-term    saturation 
avoidance    [Ref.    34].       In    light    of    these    accomplished    or    near 
term    events,    this    goal    of    providing    processing    capabilities 
to    relieve    stock    point    host    saturation    appears    out    of   date, 
in    that    it    has    been    accomplished,    and    is    no    longer 
appl ic  abl e  . 


50 


Finally,  the  third  goal  appears  as  both  not 
accomplishable  and  backward  looking.   It  is  not 
accomplishable  due  to  a  source  outside  of  NAVSUP  control: 
NAVCOMPT.   As  NAVSUP  moves  to  eliminate  non-TANDEM 
minicomputers  from  the  stock  points,  NAVCOMPT,  particularly 
with  its  PE  3210  based  NAVSCIPS  project  [Ref.  35],  will  move 
a  small  number  of  more  recent  vintage  PEs  back  in. 26   it  is 
felt  that  this  goal  is  backward  looking  in  that  the 
proliferation  of  NAVSUP  controlled  non-Burroughs  compatible 
minicomputers  at  stock  points  appears  to  have  ceased  with 
the  deployment  of  SPLICE.   Therefore,  this  goal  too  becomes 
questionable. 

In  light  of  the  above,  it  appears  that  a  new  set  of 

goals  for  the  SPLICE  project  is  necessary.   The  following 

goals  are  proposed  based  on  the  NAVSUP  Strategic  Information 

System  Plan  and  the  capabilities  available  within  the  SPLICE 

project  as  outlined  in  Chapter  2  of  this  document: 

1.   Assure  that  SPLICE  fully  supports  the  Material 

Requirements  Determination  Program,  provides  improved 
fleet  support,  and  assists  in  weapons  system  logistics 
support  requirements  by  providing  system  capacity  for 
applications,  a  comprehensive  set  of  local  and 


26it  should  also  be  noted  that  at  some  stock  points  the 
Defense  Communications  Agency  (DCA)  will  be  installing  DDN 
Interface  Message  Processors  (IMPs)  of  the  BBN  C30  series. 
This  adds  yet  another  additional  "minicomputer"  to  the  stock 
point  environment,  even  though  they  will  not  be  specifically 
responsible  for  it. 
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longhaul  data  communications  capabilities,  and  office 
automation/management  support  tools.  (NSISP27  Goal  1) 

2.  Assure  that  SPLICE  fully  participates  in  the  NAVSUP 
Information  Resources  Management  Program  including 
data  administration,  so  that  information  is  managed  as 
a  NAVSUP  corporate  resource.  (NSISP  Goal  2) 

3.  Assure  that  on-going  and  future  SPLICE  initiatives 
provide  security,  data  accuracy,  maximum  modularity 
and  flexibility,  maximum  integration,  and  a  timely 
return  on  investment.   (NSISP  Goal  3) 

4.  Assure  that  SPLICE  project  efforts  result  in  improved 
user  effectiveness,  increased  productivity,  and  better 
use  of  Navy  resources.   (NSISP  Goal  4) 

5.  Ensure  SUP  0472  develops  and  maintains  comprehensive 
SPLICE  strategic  and  tactical  plans,  performs 
effective  budgeting,  and  efficiently  manages  its 
assets  consistent  with  the  overall  NAVSUP  mission  and 
goal s.   (NSISP  Goal  6) 

6.  Assure  that  SPLICE  effectively  exploits  new  and 
emerging  information  system  technology.  (NSISP  Goal  7) 

As  can  be  seen,  these  proposed  goals  are  directly 

relatable  to  NAVSUP  Strategic  Information  System  goals  and, 

as  will  be  demonstrated  in  latter  chapters,  are  supportable 

from  existing,  planned,  or  potential  SPLICE  and  application 

project  capabilities.   With  these  goals  so  proposed,  the 

area  of  SPLICE  strategies  can  next  be  addressed. 


C.   PROPOSED  SPLICE  PROJECT  STRATEGIES 

The  SPLICE  project  has  specified  in  its  SDP  III  document 

32  project  strategies,  broken  down  into  support,  design  and 

economic  areas,  which  also  happen  to  be  termed  "objectives" 


27Each  proposed  SPLICE  goal  is  cross-referenced  to  the 
senior  level  plan  by  this  notation.   NSISP  will  be  used  as 
an  abbreviation  for  the  NAVSUP  Strategic  Information  System 
PI  an. 
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[Ref.  36].   Due  to  their  length,  they  have  been  reproduced 
as  Attac  hment  E . 

Although  these  strategies  are  not  directly  related  to 
the  later  strategies  produced  in  the  NAVSUP  Strategic  and 
Strategic  Information  System  plans,  they  appear  to  be 
comprehensive  and  well  presented. 28   jhe  major  problems  that 
become  evident  from  these  strategies  are  twofold.   First,  of 
the  32  presented,  14  are  considered  to  be  complete  since 
they  are  either  acquisition  related  or  have  been  accomplish 
through  SPLICE  Phase  I.   Those  considered  complete  are 
indicated  by  an  asterisks  next  to  the  strategy  number  in 
Attachment  E.   Second,  at  least  three  of  the  remaining 
strategies  appear  as  duplicates  or  variations  on  previously 
presented  strategies  (i.e.,  number  20  is  a  variation  on 
number  10  and  numbers  21  and  32  are  variations  on  number  3). 

Using  the  remaining  strategies,  the  NAVSUP  Strategic 
Information  System  Plan,  and  the  SPLICE  capabilities 
outlined  in  Chapter  2  as  a  basis,  a  revised  set  of  SPLICE 
project  strategies  has  been  prepared.   Again  do  to  their 
length,  the  new  strategies  are  provided  as  Attachment  F, 
instead  of  being  presented  here.   As  can  be  seen,  these 
proposed  strategies  are  directly  related  to  both  NAVSUP 
Strategic  Information  System  Plan  strategies  and  to  the 
proposed  SPLICE  project  goals  presented  earlier.   As  such. 


28More  importantly,  they  were  sufficient  to  obtain  SDP 
1 1 1  approval . 
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they  should  "fit"  better  under  the  NAVSUP  corporate  planning 
umbrella,  resulting  in  greater  impact  and  planning 
cohesiveness. 

Having  now  proposed  a  new  set  of  SPLICE  project  goals 
and  strategies,  both  directly  related  to  the  NAVSUP 
Strategic  Information  System  plan,  the  area  of  supporting 
objectives  may  now  be  addressed. 


D.   PROPOSED  SPLICE  PROJECT  OBJECTIVES 

The  final  area  of  SPLICE  planning  that  must  be  discussed 
is  that  of  objectives.   From  the  analysis  point  of  view, 
this  is  the  most  difficult  area  to  address  because  what  has 
been  defined  as  objectives  within  this  document  and  in  the 
senior  level  NAVSUP  planning  documents,  is  presented  within 
the  SPLICE  project  supporting  documentation  and  SDP  III 
document  by  a  long  series  of  POA&Ms  [Ref.  37].   For  example, 
the  NAVSUP  SPLICE  project  office  periodically  issues  a 
SPLICE  Milestone  Plan  and  Status  Report.   Within  this 
document  are  15  separate  POA&Ms  covering  all  the  project 
management,  hardware,  and  environmental  software  areas. 
Environmental  software  areas  are  further  delineated  by  FMSO 
maintained  POA&Ms.   However,  the  SPLICE  project  office  is 
not  directly  responsible  for  SPLICE  applications  nor  for 
NAVSUP  wide  telecommunications.   Therefore,  many  additional 
POA&Ms  from  other  codes  within  NAVSUP  must  be  reviewed  for 
SPLICE  application  objectives,  also  supported  by  more 
detailed  FMSO  documents,  and  still  others  for  NAVSUP 
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telecommunications  objectives,  which  do  not  appear  to  have 
corresponding  FMSO  documents. 

Little  purpose  would  be  served  by  reproducing  these  many 
documents  as  appendices  to  this  work  or  attempting  to 
summarize  them  here.   An  alternative  approach  was  selected 
wherein  the  authors  reviewed  these  documents,  discussing 
portions  with  applicable  project  managers,  and  selected  key 
milestones  to  be  incorporated  into  a  master  list  of  SPLICE 
project  objectives.   The  proposed  master  list  is  provided  as 
Attachment  G  to  this  document. 

In  reviewing  Attachment  G,  several  points  should  be 
noted.   First,  an  attempt  was  made  to  include  objectives  for 
every  major  area  in  which  the  SPLICE  project  is  currently  or 
projected  to  be  working  in,  along  with  several  additional 
areas  being  recommended  by  the  authors  for  adoption  as 
official  SPLICE  objectives.   Secondly,  each  objective  is 
cross-referenced  to  both  applicable  SPLICE  strategies  and 
NAVSUP  Strategic  Information  System  Plan  objectives. 
Finally,  estimated  completion  dates  have  been  proposed,  but 
since  limited  contact  with  the  affected  field  activities  was 
possible  during  the  time  allowed  for  this  work,  these  dates 
must  be  considered  "soft"  and  will  require  further  inputs 
prior  to  actual  adoption. 

Having  proposed  new  SPLICE  project  goals,  strategies, 
and  objectives,  the  areas  of  supporting  tactical  initiatives 
and  programs  can  now  be  addressed  in  the  next  five  chapters. 
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IV.   CENTRALLY  MANAGED  SPLICE  SUPPLY  APPLICATIONS 

A.   CHAPTER  OVERVIEW 

Two  major  categories  of  application  programs  exist  at 
the  Navy  stock  points:  FMSO  centrally  designed  and  developed 
applications  and  locally  designed  and  developed 
applications.   Within  these  categories,  six  major  functional 
application  areas  exist:  physical  distribution,  inventory 
management,  stock  point  management,  proc ur emen t/ con tr ac t i ng , 
financial  services,  and  stock  point  services. 

In  this  chapter,  centrally  developed  SPLICE  supply 
applications  in  the  first  three  areas  will  be  addressed  from 
several  aspects.   First,  proposed,  in  design,  and  already 
developed  SPLICE  supply  applications  will  be  presented  in 
terms  of  their  purpose,  including  their  defined  corporate 
support  and  benefit  area(s)  or  potential  for  increased 
corporate  support  and  benefit.   Secondly,  these  applications 
will  be  analyzed  in  terms  of  their  need  and  potential  for 
migration  to  the  SPAR  Project.   Finally,  it  will  be  shown 
how  each  application  tactically  supports  or  can  be  made  to 
better  support  the  proposed  SPLICE  objectives. 

While  performing  this  last  effort,  recommendations  will 
be  made  for  changes  to  these  tactical  or  application 
programs  to  enable  them  to  provide  greater  support  or 
benefit  to  the  "NAVSUP  corporation."   These  recommendations 
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will  tend  to  focus  more  on  the  data  processing  or 
information  system  areas  rather  than  on  the  functional 
areas.   This  is  necessary  because  the  authors  are    not,  and 
do  not  wish  to  imply  that  they  are,  qualified  systems 
analysts  in  any  of  the  functional  areas  which  SPLICE 
addresses,  but  do  understand  the  basic  business  processes. 

With  this  preview  in  mind,  the  presentation  of  SPLICE 
physical  distribution,  inventory  management,  and  stock  point 
management  application  areas  will  next  be  undertaken. 

B.   SPLICE  APPLICATION  "B"  ENHANCED  (ABE) 

Material  receiving  within  UADPS-SP  falls  under  the 
physical  distribution  functional  area.   The  receiving 
portion  of  physical  distribution  is  guided  by  a  two  cycle 
recording  concept  called  "controlled  post."   This  concept 
requires  in  cycle  number  1,  the  "in-process"  cycle,  that 
receipt  of  material  at  an  activity  be  recorded  in  an  In- 
Process  field  of  a  mechanized  Master  Stock  Item  Record 
(MSIR)  and  can  even  be  reported  as  received  to  the 
applicable  Inventory  Manager.   However,  this  initial  receipt 
cycle  does  not  increase  the  on-hand  balance  of  the  activity 
record.   The  receipt  is  then  tracked  through  cycle  number  2, 
the  "stow"  cycle,  which  concludes  with  physical  storage  and 
generation  of  a  transaction  that  updates  the  MSIR  on-hand 
quantity,  after  positive  confirmation  of 
stowage. 
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Application    B    is    the    UADPS-SP    receipt    processing 
application.       Included    within    this    application    are    programs 
which    perform    the    following    functions    [Ref.    38]: 

1.  establish,    maintain,    modify,    inquire,    and    purge    due 
records    on    the    Receipt    Due    File    (RDF)     to    the    Receipt 
Due    History    File    (RDH),    providing    financial    data 

upd  ates    as    requ  i  r ed ; 

2.  follow-up    or    cancel    overage    dues; 

3.  record    data    on    the    physical    receipt    of   material     in    the 
RDF    and    the    MSIR,    direct   material    to    the    appropriate 
locations,    notify    Application    C    to    release    issues    held 
in    the    I  n-Process/ Backord er    file,    generate    financial 
information    to    applications    E    and    F,    and    generate 
transaction    item    reports    (TIRs)    through    Application    H. 

4.  determine    disposition    of    Material    Turned    into    Stores 
(MTIS),    including    generation    of    transactions    for 
excessing    material    through    Application    M,    taking 
material     into    stock,    or    disposing    of   material,    as 
requ  i  red . 

5.  generate    management    reports    including    statistical 
reports    on    delinquent    dues,    receipt    processing 
timeframes,    and    performance    of    sources    of    supply. 

Prior    to    October    1982,    all    of    these    functions    were 

performed    at    UADPS-SP    stock    points    primarily    via    Burroughs 

COBOL    programs    on    the    Burroughs    medium    system    mainframes, 

using    remote    card    reader/punch    equipment,    card    inputs    and 

outputs,    and    hard    copy    documents    and    listings.       A    simplified 

example    receipt    transaction    will    help    explain    this    process: 

1.  physical     receipt    of   material    occurs    on    the    receiving 
floor; 

2.  documentation    is    carried    to    some    receipt    control    area 
where    information    is    transcribed    from    the    receipt 
document    to    a    punch    card    for    input/inquiry    to    the    site 
RDF    via    remote    Burroughs    card    reader/punch    equipment; 
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responses  are  returned  in  card  format,  including  a 
receipt  detail  card,  and  a  stow  card  with  possible 
trailer  information; 

the  receipt  detail  reply  cards  are  matched  to  the 
original  receipt  document  and  input  to  update 
applicable  fields  (e.g..  In-process)  on  the  RDF  and 
MSIR;  exceptions  are  returned,  corrected  and  re-input; 

stow  cards  are  attached  to  the  material  while  on  its 
way  to  the  location; 

when  the  material  is  physically  stored,  the  stow  card 
is  re-input  to  update  the  RDF  and  MSIR. 


Similar  processes  are  required  for  receipts  not  from  due, 
contract  receipts,  and  MTIS.   As  may  be  imagined,  this  card- 
oriented  and  paper- in  ten s i V e  process  was  time  consuming, 
error-prone,  and  not  conducive  to  complete  asset  visibility 
nor  management  control  and  oversight. 

For  these  reasons,  receipt  processing  had  been 
identified  as  one  of  the  earliest  potential  benefactors  from 
SPLICE  on-line  processing.   As  such,  NAVSUP  designated  the 
Receipt  Improvement  Program  (RIP)  as  one  of  the  first  and 
foremost  SPLICE  applications. 

The  benefits  to  the  corporation  from  such  a  program 
included  better  asset  visibility;  improved  asset  control; 
reduction  is  inventory  costs  due  to  lost,  erroneously 
processed,  or  stored  receipts;  increased  receiving  clerk 
productivity;  improved  fleet  support  by  having  material 
available  for  issue  faster;  and  elimination  of  obsolete  card 
oriented  hardware.   When  the  delay  in  acquiring  SPLICE 
hardware  occurred,  RIP  was  one  of  the  applications  that 
simply  could  not  wait;  the  payoffs  were  too  great  to  be 
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postponed.   The  result  was  the  creation  by  FMSO  of  Non- 
SPLICE  ABE. 

Non-SPLICE  ABE,  implemented  partially  through  new  and 
revised  core-resident  Burroughs  application  programs,  a  new 
Receipt  Control  File  (RCF),  and  using  Burroughs  terminal 
concentrators  and  terminals,  eliminated  much  of  the  card 
processing.   This  was  accomplished  by  segmenting  and 
modernizing  the  user  interface  portions  of  the  receipt 
process,  as  well  as  providing  a  NISTARS  interface. 
Specifically,  FMSO  provided  the  capability  to  eliminate 
inquiry,  receipt  detail,  stow,  exception,  and  trailer  cards 
from  receipt  processing  and  replace  them  with  CRT  inputs, 
displays,  and  printer  outputs.   A  simplified,  sample  receipt 
within  non-SPLICE  ABE  might  process  as  follows   [Ref.  39]: 

1.  when  material  is  received,  a  CRT  inquiry  is  made  to  a 
Burroughs  resident  file  to  determine  the  status  of 
this  material  (e.g.,  is  it  on  order,  recorded  as  such, 
etc.).   This  inquiry  results  in  the  computer 
assignment  of  a  5  position  Receipt  Control  Number 
(RCN)  to  this  transaction  and  the  creation  of  a  new 
receipt  control  record  in  the  Burroughs  resident  RCF 
file,  using  the  RCN  as  the  key.   Both  the  Burroughs 
MSIR  and  RDF  files  are  accessed  for  data  and  selected 
fields  are  brought  to  the  screen  and  transmitted  to 
the  RCF. 

2.  any  exceptions  to  normal  processing  are  output  to  the 
CRT  screen  for  immediate  correction  and  re-entry,  or 
to  a  designated  exception  printer.   Thus,  exceptions 
may  be  worked  prior  to  the  receipt  being  placed  in- 
process  within  Non-SPLICE  ABE  and  exception  visibility 
maintained  anywhere  within  the  receiving  process. 

3.  assuming  the  material  is  on-order,  a  stocked  item,  and 
has  been  pre-assigned  a  warehouse  storage  location,  a 
CRT  display  Receipt  Detail  Transaction  is  output  which 
contains  the  RCN.   Receipt  Detail  transactions  may  be 
further  processed  from  the  CRT  to  begin  "cycle  1." 
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These    are    edited    and    validated    prior    to    being 
forwarded    to    normal    receipt    updating    programs.       A    hard 
copy    Material    Movement    Document    (MMD)     is    also    printed 
and    attached    to    the   material    to    assist    in    storage. 

4.  all     follow-jp    receipt    actions    for    this    transaction    may 
then    be    taken    and    recorded    via    other    CRT    screens.       The 
Burroughs    RCF    record    is    continually    available    for 
inquiry    or    update    by    adjustment    transactions    to    record 
the    latest    action    against    the    received    material,    as 
well    as    NISTARS    interface    transactions. 

5.  following    completion    of    storage,    one    of    several    CRT 
stow    frames    may    be    used    to    confirm    the    storage    action 
and    initiate    cycle    2    final    update    of    the    Burroughs 
MSIR    and    RDF    files. 

In    addition,    the    implementation    of    Non-SPLICE    ABE    provided 

increased    information    about    the    status    of    the    receiving 

operation:    the    receipt    clerks    could    obtain    individual 

receipt    information    status    at    the    touch    of    a    button    and 

management    received    new    visibility    of    the    entire    site 

receiving    process    via    hardcopy    reports    providing    detailed 

status    of    non-completed    receipts    through    the    RCF    file. 

The    implementation    of    Non-SPLICE    ABE    has    been 

successfully    completed    at   many    UADPS-SP    stock    points    to 

date.       Although    successful,    Non-SPLICE    ABE    has    encountered 

probl ems : 

1.       Burroughs    Host    dependence    -      This    has    resulted    in    two 
probl ems : 

a.  when    the    Burroughs    is    down,    receiving,    shortly 
thereafter,    stops.       Although    this    can    be    tolerated 
for    short    periods    of    time,    lack    of    receiving    lay- 
down    space    at   many    activities    and    lost    worker 
productivity    during    this    time    will    not    permit    this 
situation    for    1 ong . 

b.  low    response    time    and    high    overhead    processing 
requirements.       To    achieve    an    acceptable    level    of 
terminal    response,    some    Non-SPLICE    ABE    programs 
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must    be   made    core-resident    with    scheduling    and 
execution    parameters    set    at    time    0/volume    1.       At    a 
high    volume    activity,    this    can    adversely    affect 
other    processing.       Also,    even    with    this    privileged 
processing    status,    response    times    may    be 
relatively    long. 

2.  lack    of    Burroughs    hardware    availability.       Non-SPLICE 
ABE    requires    additional    Burroughs    hardware    (i.e., 
memory,    some    disk,    and    terminal    concentrators)     that    is 
not    immediately    available    on    NAVSUP    contracts    or    that 
would    only    be    necessary    until     SPLICE.       This    latter 
situation    makes    justification    for    this    hardware    very 
difficult. 

3.  inflexibility    of   management    reports.       Although    the    new 
Non-SPLICE    ABE    management    reports    provided    a    great 
deal    of    new   management    information,    there    was    only 
limited    capability    for    management    to    perform    "ad    hoc" 
reporting,     in    user    designated    formats. 

To    resolve    these    lingering    problems,    NAVSUP    directed    that    a 

SPLICE    ABE    be    developed    for    eventual     implementation    by    all 

stock    points    [Ref.    40]. 29 

The    concept    behind    SPLICE    ABE    was    simple:    take    the    best 
from    the    successful    Non-SPLICE    ABE    implementation    and    move 
it    to    SPLICE    TANDEM    hardware    to: 

1.  provide    for    "non-stop"    receiving    for    regular    and 
contract    receipts    by    severing    immediate    receiving 
dependence    from    the    Burroughs    hosts; 

2.  provide    some    capacity    relief    to    the    Burroughs    by 
moving    six    Non-SPLICE    ABE    programs,    the    RCF    (called 
the    RKF    on    SPLICE),    and    the    receiving    terminals    and 
printers    to    SPLICE.       Additional    Burroughs    capacity 
relief    would    also    be    provided    by    directing    MSIR    and 
RDF    read-only    data    requirements    to    the    SPLICE 
Replicated    Files    vice    the    Burroughs    MSIR    and    RDF. 


^^There    ar e    currently    three    versions    of    receipt 
processing    in    place:    the    original    card    oriented    version, 
Non-SPLICE    ABE,    and    SPLICE    ABE.       Current    NAVSUP    direction 


appears  to  be  that 
be  suppo  r ted  after 
the    only    supported 


the  non-ABE  version  of 
1  June  1987  and  SPLICE 
version    sometime    after 


receiving    will     not 
ABE    will    become 
1987. 
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3.  further    decrease    receipt    processing    times    by    reducing 
CRT    response    and    document    preparation    times    when    using 
the   more    on-line    and    inquiry    oriented    TANDEM    systems; 

4.  provide    the    user    the    capability    to    generate    non- 
standard   or    ad    hoc    reports    via    TANDEM's    ENFORM 
product,    supplementing    FMSO    provided    management 
reports . 

5.  permit    the    use    of    secondary    keys    on    SPLICE    resident 
files. 

Complete    information    on    the    SPLICE    ABE    design    is    available 

in    [Ref .    41]  . 

The  processing  scenario  for  a  regular  receipt  under 
SPLICE  ABE  appears  similar  to  that  described  for  a  Non- 
SPLICE  ABE  receipt  transaction,  once  the  host  and  file 
substitutions  described  above  are  made  and  the  SPLICE 
HYPERchannel  interface  to  the  Burroughs  is  substituted  for 
the  terminal  concentrator  and  Burroughs  PEP  data 
communications  link.   A  critical  difference  is  that  in 
SPLICE  ABE,  the  receiving  terminals,  the  RCF,  and  the  CRT 
user  interface  processes  are  running  "non-stop"  on  the 
SPLICE  TANDEM  hosts,  send i ng/ r ece i v i ng  transactions  to/from 
the  Burroughs  to  complete  transactions  and  update  master 
files.   In  the  event  of  Burroughs  failure,  receiving  can 
continue  with  all  transactions  destined  for  the  Burroughs 
queued  up  on  SPLICE  and  awaiting  for  the  Burroughs'  return 
to  an  on-line  status. 

Concerning  the  second  area  of  application  analysis 
stated  in  the  overview  of  this  chapter,  the  SPLICE  ABE 
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application    can    be    now    analyzed    in    terms    of    its    need    and 
potential     for   migration    to    the    SPAR    Project.       In    reference 
to    the    need    for   migration    of    the    function,    that    goes    without 
saying,     in    that    receiving    is    and    will    remain    a    primary    stock 
point    function.       However,    the    need    for    the    SPLICE    ABE 
application    itself    being    transitioned    to    SPAR    is    highly 
dependent    on    which    remaining    Burroughs    receiving    programs 
the    SPAR    project    office    and    application    personnel    decide    to 
transition. 

It    is    assumed    that    the    pre-ABE    receiving    programs    will 
not    be    considered    for    SPAR   migration.       If    the    Non-SPLICE    ABE 
and    associated    Burroughs    receiving    programs    are    selected    by 
SPAR    for    transition,    no    SPLICE    ABE    program   migration    will    be 
required,    but    upgrade    to    the    receiving    process    will    be 
required    to    incorporate    enhancements    made    within    SPLICE    ABE. 
On    the    other    hand,    if    the    SPLICE    ABE    and    remaining 
associated    Burroughs    programs    are    selected    by    SPAR    project 
and    application    personnel     for    transition    to    the    new 
hardware,    there    will    be    a    need    to: 

1.  continue    to    provide    a   means    to    have    replicated    files 
on    SPLICE    or,    if    sufficient    processing    power    is 
available    on    the    new    hosts,    directly    obtain    MSIR    and 
RDF    file    information    from    the    transitioned    files    on 
the    new    hardware ; 

2.  provide    a   means    at    SPAR    transition    time    for    SPLICE-to- 
SPAR    proce s s- to- proce s s    and    terminal     transaction 
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passing,  and  pass  through  via  the  HYPERchannel  or  some 
other  high-speed  data  communications  link. 30 

Therefore,  the  function  must  be  migrated,  while  the  form  in 

which  this  migration  takes  is  open  to  question. 

Concerning  the  area  of  migration  potential  to  SPAR  in 
the  receiving  area,  several  comments  can  be  made.   The 
potential  for  migrating  or  transitioning  the  Non-SPLICE  ABE 
programs  would  be  appear  to  be  no  different  than  that 
present  in  transitioning  any  resident  Burroughs  on-line 
application.   However,  the  user  interfaces  (e.g.,  terminals, 
printers,  screen  formats,  inputs,  etc.)  will  mostly  likely 
be  significantly  different  and  the  programs  may  require 
backfitting  of  SPLICE  ABE  processing  improvements.   This 
remains  in  the  authors'  opinion  a  feasible  approach. 

Migrating  stock  point  receiving  to  SPAR  with  SPLICE  ABE 
also  appears  feasible  in  that  it  reduces  the  SPAR  transition 
application  workload  by  exactly  the  number  of  programs  and 
files  that  remain  resident  on  SPLICE,  maintains  the  current 
user  interface,  and  facilitates  NI STARS- to-SPAR  interface. 31 
This  approach  does  appear  to  increase  the  environmental 
workload  and  risk  in  SPAR  transition  by  forcing  the  issues 
of  Replicated  Files  and  TRANSRECON  Offload  replacement  or 


"^^This  second  requirement  exists  exclusive  of  SPLICE  ABE 
if  SPAR  wishes  to  continue  to  use  SPLICE  as  their 
telecommunications  and  terminal  concentration  medium. 

^^This  aspect  will  be  discussed  later. 
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interface  earlier  into  the  transition  period.   This  approach 
also  appears  implementable. 

The  final  area  that  will  be  addressed  is  how  SPLICE  ABE 
tactically  supports  or  can  be  made  to  better  support  the 
proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies. 
SPLICE  ABE  directly  supports  and/or  is  supported  by  the 
following  proposed  SPLICE  project  objectives:  6,  7,  12,  18, 
19,  28,  29,  32,  33,  34,  35,  41,  43,  and  44. 

There  are  several  recommendations  the  authors  have  for 

possible  enhancements  to  SPLICE  ABE  that  will  enable  it  to 

provide  greater  support  or  benefit  to  the  corporation: 

1.   Investigate  the  implementation  of  a  direct  SPLICE  ABE- 
to-NISTARS  interface. 

a.  This  interface  could  be  used  to  reduce  direct 
Burroughs  to  NISTARS  interdependence  and  thus  help 
insulate  NISTARS  from  SPAR  transition. 

b.  The  interface  could  be  used  in  several  processing 
situations.   First,  when  NISTARS  receives  incoming 
material  first  for  stow  and  material  has  not  been 
processed  by  UADPS  Central  Receiving,  NISTARS 
could  send  SPLICE  ABE  a  transaction  that  would  put 
the  receipt  in-process  within  UADPS.   SPLICE  ABE 
would  then  interface  with  the  other  Application  B 
programs  as  is  done  today.   Similarly,  NISTARS  can 
also  send  clean,  frustrated,  and  discrepant  stow 
transactions  to  SPLICE  ABE  for  recording  and 
further  transmission  to  other  Application  B 
programs/ proces ses .   If  SPLICE  ABE  processes  the 
receipt  first,  the  expectant  stow  transaction  and 
any  similar  transactions  could  also  be  sent  to 
NISTARS  from  SPLICE  ABE  via  this  link. 

c.  A  second  major  use  of  this  interface  would  be  the 
ability  for  either  SPLICE  or  NISTARS  terminals  to 
access  the  files  of  the  other  system  for  inquiry 
or  possibly  update  purposes.   In  tnis  manner  any 
SPLICE  resident  terminal  user  could  also  be 
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afforded  NISTARS  and  ABE  file  access  to  accomplish 
tasks  such  as  researching  inventory  discrepancies 
from  the  SPLICE  TLOD  application. 

Investigate  the  incorporation  of  both  TANDEM  based  bar 
code  reading  and  printing  equipment  into  SPLICE  ABE 
r  e  c  e  i  V  i  n  g  . 

a.  A  bar  code  interface  board  to  which  commercially 
procured  reader  equipment  may  be  attached  is 
already  an  option  on  TANDEM  6530  terminals.   These 
bar  code  reader  interface  boards  could  be 
immediately  available  using  the  SPLICE  contract 
substitution  clause.   Reader  equipment  would 
require  open  procurement;  however,  the  Logistics 
Applications  of  Automated  Marking  and  Reading 
Symbols  (LOGMARS)  project  may  be  of  assistance 
here . 

b.  Medium  and  heavy  duty  laser  printers,  which  are 
capable  of  printing  bar  code  documents,  are  being 
procured  and  interfaced  to  SPLICE  as  a  part  of  the 
APADE  project.   Similar  or  even  more  heavy  duty 
printers  can  also  be  obtained  and  interfaced. 

c.  Bar  code  readers  on  SPLICE  ABE  terminals  could  be 
used  to  input  document  number,  stock  number,  or 
RCN  information,  as  part  of  the  SPLICE  ABE 
initial32  or  follow-up  inquiry  function.   Remote 
bar  code  printers  from  SPLICE  could  be  used  to 
print  labels  for  material  or  bins,  that  could 
subsequently  be  used  in  inventory  and  issue 
processing.   Also,  document  number,  stock  number, 
and  location  data  could  be  bar  coded  on  MMDs, 
which  would  require  only  re-wanding  after  storage 
to  initiate  the  SPLICE  ABE  storage  transactions. 

Investigate  the  use  of  a  more  direct  interface  between 
SPLICE  ABE,  Application  B,  and  the  under  development 
SPLICE  Defense  Data  Access  (DDA)  System.   Such  an 
interface  could  be  used  to  automatically  input 
transactions  to  Application  B  processes  which 
previously  were  received  via  AUTODIN/OLA,  as  well  as 
forward  on-line  Application  B  external  outputs  to 
ICP  s/ 1 tem  Manag  er s . 

Investigate  the  downloading  of  program  UA51,  RDF  scan, 
exception,  notification  output,  and  follow-up 


-^^Assumes 
labels  in  the 


that  incoming  receipts  will  contain  bar  code 
immed  iate  future . 
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transaction  generation  to  SPLICE  using  Replicated 
Files.   This  would  provide  additional  capacity  relief 
to  the  Burroughs,  as  well  as  permit  more  timely  and 
frequent  processing.   Any  RDF  or  MSIR  master  file 
update  actions  that  now  originate  from  this  process 
would  be  sent  to  the  Burroughs  for  master  file 
updating. 

5.  Investigate  the  movement  of  the  entire  B07  Operation, 
Management  Products,  to  SPLICE,  using  the  SPLICE 
resident  and  replicated  files.  Implement,  where 
possible  with  ENFORM. 

6.  Investigate  the  development  of  a  SPLICE  MTIS  external 
user  (i.e.,  for  use  by  ships)  screening  and  tracking 
process  using  REP  FILES.   This  process  should  be 
executable  by  remote  users,  particularly  from  a 
shipboard  DDN  customer,  with  o ut put/ resul t s  returnable 
to  the  user.   This  process  would  indicate  to  the  user 
which  material  to  bring  to  the  Supply  Center,  where  to 
deliver  it,  indicate  whether  financial  credit  will  be 
given  for  the  return  and  any  special  processing 
instructions,  indicate  which  material  should  be  sent 
directly  to  disposal,  and  begin  a  tracking  cycle  for 
selected  material,  especially  high  value  turn-ins. 


This  concludes  the  discussion  of  SPLICE  ABE 


The 


second  SPLICE  physical  distribution  application,  the  NAVADS 
project  will  be  addressed  next. 33 

C.   NAVY  AUTOMATED  TRANSPORTATION  DOCUMENTATION  SYSTEM 
(NAVADS) 

NAVADS,  like  ABE,  is  a  central  player  in  the  physical 

distribution  function  at  the  NAVSUP  stock  points.   Also  like 

ABE,  it  was  one  of  the  original  SPLICE  designated 

applications  that  required  immediate  development  and 

deployment  when  the  SPLICE  project  was  delayed  in  1979. 


33it  had  been  the  authors'  intention  to  discuss 
SPLICE  initiatives  in  the  "G"  Condition  Depot  Level 
Repairables  area.   Requested  documentation  on  this 
application  was  not  received. 
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the 


The  NAVADS  system  provides  stock  points  with  automated: 

1.  basic  shipment  related  data  for  use  in  other  modules; 

2.  management  control  of  their  shipping  function  and 
shipment  consolidation  recommendations; 

3.  shipment  documentation  preparation,  including  proof  of 
sh  i  pmen t . 34 

The  first  two  subsystems  are  Burroughs  resident  and  are 
planned  to  remain  so.   It  is  the  third  subsystem,  Subsystem 
III  or  the  Automated  Documentation  Subsystem,  that  is 
designated  for  SPLICE  transition  from  its  current  PE  3200 
series  hardware  implementation,  using  the  OSMT/32  operating 
system  and  utilities,  the  FMSO  INS  data  communications 
software,  and  the  TAPS  software. 

NAVADS  Subsystem  III,  which  will  be  referred  to  as 
simply  NAVADS  hereafter,  is  a  very  large  application 
consisting  of  about  130  interactive  and  batch  programs.   For 
specific  processing  information,  readers  are  directed  to 
[Refs.  42  and  43].   A  general  overview  of  processing 
capabilities  will  be  presented  here  to  assist  the  reader  in 
understanding  this  complex  and  heavily  interfaced 
appl ic  at i  on . 

Processing  within  NAVADS  begins  with  the  receipt  by  the 
PE  system  of  requisition  and  shipment  unit  information  from 
the  Burroughs  resident  Subsystem  II.   This  information  may 
either  be  passed  via  a  telecommunications  line  or  in  batches 


34References  to  transhipment  and  local  delivery  modules 
have  been  observed  but  no  specific  information  on  these 
impacting  SPLICE  was  received  from  FMSO. 
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via  tape  from  the  Burroughs  host.   Received  information  is 
posted  in  up  to  three  NAVADS  PE  TAPS  files:  the  Requisition 
Data  File,  the  Shipment  Unit  Data  File,  and  the  Hazardous 
Requisition  Data  file,  if  required.   Once  established  in 
these  files,  the  NAVADS  system  maintains  positive  control 
and  provides  a  tracking  capability  against  both  material  and 
shipments  until  all  shipment  and  proof  of  shipment  actions 
required  have  been  completed. 

Once  shipment  data  is  loaded,  NAVADS  users  may  apply: 
inquiries  as  to  workload  status;  packing  floor  and  shipping 
updates;  input  tracking  or  shipping  modification  information 
to  the  requisition  and  shipment  unit  Shipment  Control 
Numbers  loaded  from  Subsystem  II  and/or  to  the 
transportation  unit  Shipment  Control  Numbers  assigned;  and 
produce  local  hardcopy  listings  to  assist  in  work' scheduling 
or  job  staging.   These  inputs  are  primarily  CRT  originated, 
using  Burroughs  compatible  devices,  with  outputs  both  CRT 
and  remote  printer  destined. 

While  a  shipment/transportation  unit  is  passing  through 
all  required  preparation  and  handling,  shipping 
documentation  is  prepared  on-line  and  printed  at  remote 
printers  in  the  shipping  area.   Shipping  documentation 
includes  Government  Bills  of  Lading,  Commercial  Bills  of 
Lading,  Military  Shipment  Labels  (DD  1387-4),  Transportation 
and  Movement  Documents  (DD  1384),  and  Notices  of 
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Availability    (DD    1348-5).       These    various    documents    are 
affixed    to    shipping    containers    as    required. 

NAVADS    completes    its    processing    by    preparing    proof   of 
shipment    documents    which    can    be    forwarded    back    to    the 
Burroughs    hosts    either    on-line    through    telecommunications 
lines    or    via    batch    tape    updates.       It    also    prepares 
transaction    images    which    are    destined    for    AUTODIN    I 
transmission    (e.g..    Notices    of    Availability,    Transportation 
Control    and    Movement    Documents,    etc.). 

NAVADS    has    a    direct    NISTARS    TANDEM    Non-Stop    II     interface 
role.      This    interface    is    physically    accomplished    via    another 
telecommunications    line    and    through    tape    passing.       Interface 
transactions    between    NAVADS    and    NISTARS    include    cancellation 
processing;    piece,    weight,    cube    updates;    issue    adjustment 
transactions;    split    shipment    unit    transactions;    shipment 
mode    changes;    Parcel    Post/United    Parcel    Service    (UPS)    Proof 
of    Shi  pmen t . 

Finally,    NAVADS    provides   management    a    whole    series    of 
reports    to    assist    in    keeping    tabs    on    the    response    time 
critical     shipping    operation.      These    include:    On-Line    Local 
Delivery    Report,    Batch    Shipment    H i story/ Report ,    Overaged 
Local    Delivery    Report,    Overaged    Parcel    Post/UPS    Requisition 
Report,    Outstanding    Transshipment    Report,    Requisition    Late 
to    Packing    Report,    and    the    Batch    Tonnag e 'D i str ib ut i on 
Report,    to    name    a    few. 
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The  transition  strategy  from  PE  NAVADS  to  SPLICE  NAVADS 
is  to  keep  the  transition  as  transparent  as  possible  to  the 
application  by  porting  TAPS,  in  its  updated  TAPS  II  PASCAL 
form,  to  the  SPLICE  TANDEM  system.   Now  that  TAPS  II  is 
available  on  SPLICE,  current  screens  will  be  reimplemented 
in  TAPS  II,  files  moved  to  TANDEM  ENSCRIBE  format  and 
interfaced  to  TAPS  II,  programs  re-compiled  into  TANDEM 
COBOL  and  interfaced  to  TAPS  II,  and  terminal  device  and 
security  functions  placed  under  the  control  of  the  FDC's 
SAS/TMAP  processes.   Without  processing  efficiency 
enhancements,  TAPS  II  on  TANDEM  is  not  a  usable  product  in 
an  operational  environment.   These  enhancements  are  being 
undertaken.   The  alternative  method  to  get  NAVADS  to  SPLICE 
would  required  a  complete  re-design  by  FMSO  of  the  current 
system  into  the  TANDEM  native  mode  TPS  using  PATHWAY  and 
ENCOMPASS,  prior  to  any  usage  on  SPLICE.   Economic 
justification  of  this  alternative  would  be  difficult  and 
would  require  continued  PE  TAPS  support  during  the  duration. 

The  benefits  to  the  corporation  from  NAVADS  are 
documented  in  [Ref.  42]  and  include:  optimization  of 
shipping  personnel  resources,  positive  control  of  and 
reporting  on  the  status  of  the  pac k i ng/ shi ppi ng  process  at  a 
site,  workload  planning  and  staging  tools,  automated 
preparation  of  labels  and  forms  required  for  shipping, 
automatic  proof  of  shipment  passed  to  UADPS-SP,  and  an 
automated  NISTARS  interface.   However,  these  benefits  exist 
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regardless    of    any    SPLICE    initiatives.       Transition    of    NAVADS 
to    SPLICE    additionally    will     provide    the    corporation    four 
things:    a    reduction    in    non-SPLICE    minicomputer    system 
support;    non-stop    shipping    support;    a    reserve,    expansion, 
and    growth    capability    for    NAVADS;    and    the    potential     for 
developing    an    integrated    physical    distribution    function. 

The    transition    of    NAVADS    to    SPLICE    eliminates    the    need 
for    approximately    one    half    of    the    PE   minicomputers    in    the 
NAVSUP    inventory;    the    other    half   being    used    on    FMSO    IDA. 
This    helps    achieve    one    of    the    original    SPLICE    objectives:    to 
standardize    stock    point   minicomputers.       This    also    reduces 
the    need    for    vendor    software    support    for    NAVSUP    PE    systems 
as    well    as    FMSO    support    for   multiple    versions    of    TAPS    and 
current    FMSO    developed    and    maintained    INS    software. 
Software    lease    and    maintenance    as    well    as    personnel     savings 
can    accrue    to    the    corporation    from    this.       As    a    longer    term 
benefit,    the    number    of   different   minicomputers    which    SPAR 
must    interface    to,    and    later    absorb,    will    be    reduced. 

NAVADS    on    PE    has    periodically    suffered    from    both 
hardware    and    software    problems    that    have    brought    the    system 
to    its    knees    and    subsequently    backlog ged    the    NAVADS    shipping 
documentation    efforts.       In    a    single    processor,    non-mirrored 
disk,    and    single    host    resource    environment,    such    as    is 
present    in    the    PE    system,    this    will    always    be    a    potential 
problem.       Since    SPLICE    has    no    single    point    of    failure, 
employs   mirrored    disks    to    protect    data,    and    has    facilities 
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for    sharing    peripheral     resources,    system    uptime    and 
availability    should    be    significantly    improved    when    NAVADS 
moves    to    SPLICE. 

The    PE    implementation    of    NAVADS    had    also    experienced    a 
capacity    problem    from    its    inception    at    its    prototype    site, 
NSC    Oakland.       This    was    evidenced    by    what    was    termed    "the 
systems'     inability    to    complete    a   day's    worth    of   business 
within    24    hours."       After    numerous    FMSO    system    tunings    and 
program    efficiency    modifications,    the    immediate    problems 
were    resolved,    but    the    long    term    specter    of    no    growth,    nor 
surge,    and    limited    expansion    capability    has    remained    with 
the    application.      Additionally,    the    source    for    large    enough 
PES    for    follow-on    sites    has    remained    a    question.       SPLICE    on 
TANDEM,    with    its    available    host    capacity    (i.e.,    1,040    4MB 
memory    processors)    and    modular    expansion    capability, 
requiring    no    application    changes    to    accommodate    growth,    can 
provide    the    solution    to    this    problem. 

Lastly,    in    the    interim    to    SPAR,    SPLICE    holds    the    key    to 
integrating    the    non-Burroughs    portions    of    the    physical 
distribution    system.      With    SPLICE    ABE    and    NAVADS    on    TANDEM 
TXP    hosts,    NISTARS    on    TANDEM    Non-Stop    II    hosts,    and    the 
ability    of    TANDEMs    to    logically    function    as    a    single    system 
using    off-the-shelf    software,    the    potential     for    integrating 
or    eliminating    transactions,    files,    and    non-TANDEM 
interfaces    among    these    systems    is    very    large.       This    will 
depend    on    FMSO's    ability    to    assume    the    NISTARS    system    from 


74 


contractor  support  and  being  funded  to  perform  the  needed 
integration  actions. 

Assuming  the  transition  of  NAVADS  to  SPLICE,  there  is  no 
need  for  migration  of  NAVADS  to  the  SPAR  transition 
environment.   The  SPLICE  terminal  and  proc es s- to- proc ess 
interfaces  to  SPAR  will,  however,  also  be  required  here. 
When  SPLICE  is  replaced  by  modernized  SPAR,  the  SPLICE 
resident  functions  of  NAVADS  will  require  migration,  but  not 
the  current  processes.   Elimination  of  SPLICE  NAVADS  will 
require  both  redesign  and  development  on  the  new  system. 

Once  NAVADS  transitions  to  SPLICE,  it  will  tactically 
support  or  can  be  made  to  better  support  the  following 
proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies:  6,  7, 
8,  12,  13,  14,  15,  18,  19,  29,  32,  35,  41,  47. 

The  authors  have  several  recommendations  for  possible 
enhancements  to  NAVADS,  when  transitioned  to  SPLICE,  that 
will  enable  it  to  provide  greater  support  or  benefit  to  the 
corporation.   These  are: 

1.  Investigate  the  integration  potential  for  NAVADS  and 
NISTARS  files,  transactions,  and  interfaces. 
Particularly,  investigate  the  use  of  NISTARS 
transactions  to  update  NAVADS  files  directly  and  vice 
versa  and  the  substitution  of  new  common  files  instead 
of  separate  files  containing  redundant  data. 

2.  Investigate  the  interface  of  NAVADS  to  DDA  in  order  to 
pass  AUTODIN  I  destined  transactions  directly  into  the 
system . 

3.  When  economically  justified,  replace  the  less 
functionally  capable  Burroughs  terminals  with  either 
TANDEM  or  IBM  3270  series  compatible  terminals. 
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4.  Investigate  the  distribution  of  NAVADS  management 
reports  to  local  management  via  TANDEM  TRANSFER  or 
PS/Mail,  thus  reducing  hardcopy  and  paper  output 
requirements. 

5.  Investigate  the  use  of  the  TANDEM  T-Text  Word 
Processing  capability  to  replace  COBOL  programs 
currently  generating  transportation  documents,  similar 
to  that  which  is  being  done  in  APADE. 

6.  Develop  a  plan  to  transition  the  NAVADS  application 
off  TAPS  II  entirely  to  native  mode  TANDEM 
PATHWAY/ENCOMPASS.   During  PE  to  SPLICE  transition  of 
Subsystem  III,  convert  batch  programs  to  TANDEM  native 
TPS  mode,  where  economically  feasible. 35 

7.  If  additional  Burroughs  capacity  relief  or  downloads 
are  desirable,  investigate  the  download  of  both  NAVADS 
Subsystems  I  and  II  to  SPLICE.   There  appears  nothing 
in  either  subsystem  which  mandates  their  processing  on 
the  Burroughs.   If  accomplished,  this  would  return 
capacity  to  the  Burroughs,  reduce  SPAR  transition 
requirements,  permit  NAVADS  to  be  implemented  at  any 
stock  point  where  SPLICE  is  planned,  and  more  closely 
integrate  and  collocate  physical  distribution 
functions  on  the  TANDEM  systems. 

With  these  recommendations  completed,  the  NISTARS 

application  will  next  be  addressed. 


D.   NAVAL  INTEGRATED  STORAGE,  TRACKING,  AND  RETRIEVAL  SYSTEM 
(NISTARS) 

NISTARS  is  not,  nor  has  it  ever  been,  a  SPLICE 

application.   It  is  not  SPLICE  targeted  and  is  still  today  a 

contractor  maintained  system.   It  is  being  included  under 


^Sjhe  authors  are  assuming  that  the  original  TAPS  II 
conversion  specifications,  which  called  for  the  interface 
and  use  of  ENSCRIBE  files  instead  of  TAPS/DM  VISAM  files, 
was  executed.   If  so,  standard  PATHWAY  or  TANDEM  COBOL 
programs  should  be  able  to  process  against  these  files 
concurrently  with  TAPS/AM  applications.   The  specification 
was  so  worded  to  enable  a  phased  transition  from  TAPS  II  to 
TANDEM  native  mode  processing. 
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this  section  on  centrally  designed  SPLICE  applications 
because  the  authors  feel  that  the  future  deployment  of 
certain  NISTARS  concepts  and  programs  on  SPLICE  can  assist 
the  corporation  in  accomplishing  one  of  its  primary 
missions:  maintenance  of  accurate  physical  inventories  and 
inventory  records  in  the  logistics  system. 

NISTARS  is  NAVSUP's  flagship  integrated  physical 
distribution  system. 36   When  fully  implemented,  NISTARS  will 
be  able  to  automatically  or  with  minimal  user  input  control: 
inventory  of  parts  and  material;  receipt  processing 
including  assignment  of  storage  area;  storage,  tracking  and 
retrieval  of  material  for  issue;  consolidation  of  orders; 
and  printing  of  shipment  documents.   The  system  is 
considered  a  "closed  loop  system."   That  is,  it  accepts 
known  inputs  from  external  sources,  performs  predefined 
functions  based  upon  the  content  of  the  input,  and  reports 
the  results  of  its  action  back  to  input  source.   The  end 
results  or  benefits  to  NAVSUP  of  these  activities  are 
greater  consistency  in  management  and  control  of  existing 
and/or  expanded  high  demand  parts  inventories  with  fewer 
personnel,  in  a  shorter  time,  and  with  greater  accuracy. 

Although  these  benefits  were  originally  expected  to 
accrue  to  only  the  NISTARS  mechanized  areas  where  high 
volume,  fast  moving  items  would  be  placed,  with  the 


36it  is  also  probably  the  most  audited  due  to  its 
implementation  slippage  and  cost  increases. 
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publicizing    of    the    NAVSUP    inventory    accuracy    problems    in    the 
early    1980s    a    re-evaluation    of    this    concept    was    undertaken 
[Ref.    44].       High    volume    items    represent    a    low    percentage    of 
the    inventory    cost    of    the    supply    system;    to    get    real    control 
of    inventory    accuracy,    NISTARS    control    needed    to    be    extended 
to    non-mechanized    warehouses.      The    NISTARS    project    was    able 
to    accommodate    this    change    of   direction    for    planned    sites    by 
program    changes    and    procuring    an    increased    number    of    the 
NISTARS    intelligent    workstations. 

NISTARS    was    originally    designed    and    designated    as    an 
"embedded"    vice   general    purpose    ADP    system:    85%    of    the 
system    is    considered    process    control    and    15%    interface 
oriented.      This    designation    had    been    challenged    by    6A0    in 
1979,    but    the    Navy    did    not    concur    with    the    finding.       It 
maintained    that    NISTARS    is    a    process    control    computer 
embedded    in    an    automated    material    handling    system    (AMHS) 
and,    as    such,    should    not    be    procured    under    the    Brooks    Act 
(PL    89-306)     as    would    any    other    general    purpose    ADP    system. 
The    NISTARS    "embedded"    system    designation    was    useful    at    the 
time    of    initial    system    procurement    since    it    eliminated 
several    review    and    approval     steps. 

The    total    NISTARS    "embedded"    system    consists    of    various 
automated    material    handling    equipment    components    (e.g.,    tote 
boxes,    manned    storage    retrieval    machines,    m i n i stac ker s  , 
binable    manual     storage    retrieval    machines,    conveyors, 
sorters,    consolidation    carousels,    etc.),    TANDEM    Non-Stop    II 
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host  processing  systems,  intelligent  workstations  for  user 
interface,  and  software  modules  that  perform:  interface, 
issue,  receipt,  tracking,  warehouse  planning,  storage 
location  management,  performance  reporting,  and  management 
reporting.   The  NISTARS  processing  activities  are  driven  by 
other  data  processes  within  mainline  UADPS-SP,  Non-SPLICE 
ABE,  and  PE  NAVADS,  by  means  of  both  on-line  data 
communications  and  batch  tape  inputs. 

A  detailed  discussion  of  planned  NISTARS  functions  is 
available  in  [Ref.  45]  and  interface  requirements 
specifications  in  [Ref.  46].   Due  to  the  large  number  of 
functions  and  transactions  performed  by  NISTARS  and  limited 
documentation  held  by  the  authors,  no  attempt  will  be  made 
to  provide  sample  NISTARS  transactions  or  processing 
scenar  ios . 

Currently,  NISTARS  is  implemented  at  NSC  Oakland  and 
planned  for  NSCs  San  Diego,  Norfolk,  and  Jacksonville.   No 
definitive  plans  for  NISTARS  implementation  or  commercial 
automated  material  handling  system  alternatives  for  the 
other  stock  point  hosts  or  satellite  sites  were  uncovered 
during  this  research. 

If  no  changes  to  current  plans  are  made,  NISTARS  must  be 
Interfaced  to  the  SPAR  transition  environment,  both 
physically  and  prog rammati cal 1 y .   This  will,  at  a  minimum, 
require  changes  within  the  NISTARS  interface  module  (e.g., 
no  Burroughs  telecommunications  to  support).   At  some  point 
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during  SPAR  modernization,  NISTARS  functionality  oiust  be 
subsumed  by  SPAR,  as  the  current  NISTARS  hardware  approaches 
obsolescence.   If  the  recommendations  which  follow  are 
adopted,  NISTARS  will  be  shielded  from  SPAR  transition  by 
SPLICE,  but  will  still  require  replacement  by  the  post- 
SPLICE  modernized  SPAR  system. 

Before  any  recommendations  in  this  area  can  be  made,  it 
should  be  noted  that  a  "political"  roadblock  stands  between 
NISTARS  and  SPLICE  integration.   SPLICE  is  designated  as 
supporting  general  purpose  ADP  system  applications,  most  of 
which  require  LCM  approval  independent  of  SPLICE  itself. 
This  difference  in  designation  between  NISTARS  (embedded) 
and  SPLICE  (general  purpose)  can  preclude  the  NI STARS-SPLICE 
interface  recommendations  already  discussed  within  the 
SPLICE  ABE  and  NAVADS  application  sections  above,  at  least 
from  the  NISTARS  side,  and  those  recommendations  to  be 
presented  below.   Although  this  difference  in  system 
designation  may  be  a  problem,  it  is  considered  a  political 
one,  not  an  ADP  one.   The  authors  will  advocate  several 
additional  technically  feasible  interfaces  between  the 
NISTARS  and  SPLICE  projects  that  are  in  accordance  with  the 
corporation's  information  system  plan.   The  political 
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"initiatives"  to  implement  the  recommendations  are  left  for 
others  to  masterm i nd . 37 

The  authors  propose  the  following  additional  actions  in 
the  area  of  N I STARS-SPL I CE  integration  be  pursued,  following 
government  acceptance  and  support  of  NISTARS: 

1.  Move  the  Navy  Systems/NISTARS  Interface  function  to 
SPLICE. 

a.  This  relieves  the  Burroughs  of  the  NISTARS  data 
communications  interface  requirement;  accomplishes 
a  NAVSUP  Strategic  Information  System  Plan 
objective  of  removing  telecommunications  devices 
off  the  Burroughs  FEPs;  and  physically  insulates 
NISTARS  from  SPAR  transition. 

b.  All  TANDEMs  within  a  stock  point  can  be  interfaced 
to  the  Burroughs  solely  through  the  SPLICE 
HYPERchannel  connection.   NI STARS- to-SPLI CE 
interface  can  be  accomplished  via  TANDEM 
EXPAND/FOX  or  high  speed  TANDEM  EXP  AND /D i r ec t 
Connect  links.   This  would  eliminate  the  support 
requirement  for  the  Burroughs  Tributary  Monitor,  a 
non-standard  TANDEM- to-Burroug hs 
telecommunications  software  package  in  NISTARS. 

c.  The  functional  movement  of  the  NISTARS  interface 
function,  validation,  and  edit  routines  to  SPLICE 
returns  some  capacity  to  the  NISTARS  systems  which 
can  be  used  for  other  NISTARS  initiatives. 

2.  Provide  for  all  future  NISTARS  TANDEM  capacity 
enhancements  and  future  maintenance  via  the  SPLICE 
contract. 

a.   The  SPLICE  available  TANDEM  technology  is  more 
current  and  the  pr i c e/ per fo rmanc e  ratios  and 


37it  may  be  useful  to  note  that  NAVSUP  has  a  blanket 
approval  from  NAVD AC/ NAVM AT  to  "download"  functionally 
equivalent  or  "change  of  media"  UADPS-SP  processes  to 
SPLICE.   Once  NISTARS  becomes  an  accepted  UADPS-SP 
application,  it  could  be  argued  that  the  non-mechanized 
warehouse  portions  of  NISTARS,  exclusive  of  the  AMHS 
processes  and  hardware,  may  be  functionally  transitioned  to 
SPLICE  replacing  existing  manual/card  processes,  via  mere 
notification  in  follow-on  SPLICE  SDP  document  submissions. 
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volume    discounts    are   much    higher    than    that 
obtainable    from    Sperry. 

b.  Monetary    savings    can    accrue    to    the    government    by 
having    a    single   maintenance    contract    (e.g.,    spares 
support,    start-up    costs,    etc.)     for    all    TANDEM 
hardware    at    a    single    NAVSUP    stock    point.       The 
NISTARS    hardware,    once    government    owned,    can    be 
covered    by    the    SPLICE    maintenance    contract, 
instead    of    a    separate    contract    to    Sperry. 

c.  In    a    related    vein,    consideration    should    be   given 
to    replacing    all     the    NISTARS    processors    with 
SPLICE    Non-Stop    TXPs    and    re-deploying    the    Non-Stop 
lis    to    future    SPLICE    MAPS    sites.       Most    MAPS    sites 
do    not    appear    to    require    the    full    TXP    minimum 
configuration    to    perform    their   mission.       NISTARS 
priority,    foot    print    requirements,    backup 
requirements,    and    need    for    commonalty    with    SPLICE 
hardware    at    a    host    site    would    justify    this    step. 

Upgrade    all    NISTARS    environmental     software    to    current 
SPLICE    levels    and    maintain,     in    support    of    the 
following: 

a.  Current    NISTARS    non-standard    recovery    methods 
should    be    upgraded    to    off-the-shelf    Transaction 
Monitoring    Facility    procedures,    with    additional 
capacity    required    provided    by    SPLICE. 

b.  Current    NISTARS    application    routines    written    in 
TANDEM    Transaction    Application    Language    (TAL) 
(equivalent    to    assembler    language)     should    be 
identified,    isolated,    and    transitioned    to    TANDEM 
COBOL    or    FORTRAN,    with    SPLICE    providing    any    needed 
additional    capacity.       This    will    make    these 
routines    more   maintainable    by    the    government    and 
portable.       If    this    is    not    possible,    task 
maintenance    of    these    routines    to    FDC    as    part    of 
on-site    FMSO    support. 

c.  The    NISTARS    applications    written    in    the    pre- 
PATHWAY    TPS    should    be    upgraded    to    PATHWAY.       This 
means    less    development    software    to    have    to    train 
for,    maintain,    and    distribute,    as    well    as    having    a 
single    TPS    which    is    supported    by    TANDEM    corporate. 

d.  NISTARS    applications    should    be    interfaced    to    the 
SPLICE    Security    Access    System.       This    provides    a 
secure   mechanism    for    other    SPLICE    application 
systems    to    interface    to    NISTARS    and    provides    a 
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single    security    system    for    all     stock    point    TANDEM 
appl ications. 

e.       When    all    NISTARS    software    is    at    SPLICE    release 
levels,    future    FMSO    release,    maintenance,    and 
testing    of    TANDEM    off-the-shelf    software    will     be 
grea tl y    f ac  i 1 i  tated . 

4.  Investigate    the    augmentation    or    replacement    (when 
required)    of    the    $30,000    Sperry    Intelligent    Remote 
Terminals    (IRTs)    with    IBM    compatible    Personal 
Computers    (PCs)    or    TANDEM    DYNAMITE    workstations, 
configured    with    bar    code    readers,    printers,    magnetic 
badge    readers,    etc.,    to    perform    required    functions. 

5.  Isolate    NISTARS    non-mechanized    warehouse    processing 
applications    in    each    NISTARS    functional    area, 
repackage,    and    export    as    a    Mini -NISTARS    application    to 
all    non-NISTARS    stock    points    using    SPLICE.       This    will 
assist    the    "system"     in    inventory    accuracy.       If    in    fact 
non-mechanized    NISTARS    warehouse    control    at    current 
NISTARS    sites    does    assist    in    inventory    accuracy, 
exportation    to    all    SPLICE    host    sites    should    also    be 
justified    and    " sel f- f i nanc i ng "     in    terms    of   monetary 
saving    from    improved    inventory    accuracy.       Use    results 
of    recommendation    4    above    for    non-mechanized    IRTs. 

6.  Refer    to    recommendations    in    SPLICE    ABE    and    NAVADS 
areas    for    further    functional    area    integration    efforts. 

The    result    of    this    NI STARS-SPLI CE    marriage    will    be 
tactical    support    for    the    following    proposed    SPLICE    project 
objectives:    6,    7,    8,    9,     11,    12,    19,    28,    29,    32,    33,    38,    41, 
and    48. 

This    concludes    the    discussion    on    NISTARS-SPLICE 
"merger."       The    SPLICE    REP    FILES    and    TRANSRECON    Offload 
initiatives    will    be    addressed    next. 


E.       REPLICATED    FILES    (REP    FILES)    AND    TRANSACTION 
RECONSTRUCTION    (TRANSRECON)    OFFLOAD 

REP    FILES    and    TRANSRECON    Offload    are    not,    strictly 

speaking,    "applications."      They    are    environmental    mechanisms 


from  which  application  rich  off-shoot  areas  have  emerged: 
the  SPLICE  Information  Center  and  Application  "P"  Inquiry 
System.   In  that  these  processes  are  so  interrelated,  they 
will  be  addressed  within  a  single  area. 

The  history  of  REP  FILES  and  TRANSRECON  Offload  is  not 
long  in  terms  of  years;  they  have  only  existed  since  1983. 
The  first  to  evolve  conceptually  was  REP  FILES,  with 
TRANSRECON  Offload  developed  as  the  means  to  implement  it. 

During  the  1982-1983  timeframe,  NAVSUP,  NAVDAC,  FMSO, 
selected  stock  point  representatives,  and  the  Federal 
Simulation  Center  were  addressing  the  interim  stock  point 
capacity  issue,  with  a  direct  tasking  to  come  up  with  firm 
recommendations  to  ensure  that  sufficient  usable  capacity 
would  be  available  to  get  the  stock  points  through  the  1980s 
or  until  SPAR  could  provide  the  final  solution.   The  problem 
was  mul ti faceted .   SPAR  was  too  far  away.   SPLICE  promised 
capacity  but  few  applications  to  use  it.   Burroughs  was 
wavering  on  producing  more  B4800s  and  hinting  at  a  new 
B4900.   Faced  with  such  a  tasking,  the  various  factions 
present  brought  in  their  hired  consultants  to  provide 
corroboration  to  their  versions  of  "what  should  be  done." 

Besides  those  contractors  which  studied  the  issue  and 
simply  recommended  replacing  the  whole  UADPS-SP  system 
immediately  or  advocated  sole  source  procurement  of  large 
Burroughs  hosts  as  solutions,  one  proposal  suggested  a  usage 
of  the  IBM  Information  Center  concept.   Specifically,  it  was 
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proposed    that    either    tape    extracts    or    periodic    electronic 
images    of    Burroughs    data    files    be    loaded    in    another    format 
(e.g.,    a    DBMS    or    data    manager)    on    an    IBM    or    plug    compatible 
host,    and,    then,    subsequent    redesign    of    selected 
applications    be    undertaken    to    use    this    data    there    instead    of 
processing    on    the    Burroughs.       Among    the    applications 
suggested    for    use    in    what    was    termed    an    "information    center" 
were    terminal    and    batch    inquiry    processing,    the    UADPS-SP 
effort    to    provide    users    ad    hoc    reporting    (UH30    SUPERSCAN), 
and    End-of-Day    processing. 

The    idea    had    merit    but    was    discarded    for    several 
reasons.      Without    SPLICE    or    some    similar    effort,    the 
existing    Burroughs    compatible    terminal    base    could    not    be 
used    on    other    systems.       Using    multiple    terminal    types    was 
inadvisable    due    to    procurement    costs    and    space    limitations 
at    the    stock    points.       Regardless    of    the    terminal     issues, 
stock    point    representatives    indicated    that    unless    the 
replicated    data    was    "simultaneously"    updated    along    with    the 
Burroughs   master,    it    was    not    current    enough    for    their    users 
and    would    not    be    used.       These    problems    eliminated    the    on- 
line   inquiry    applications    from    further    consideration.      The 
tape    data    extract    concept    to    move    po st-TRANSRECON    End-of-Day 
processing    was    also    discarded    because    so    much    of    End-of-Day 
processing    required    the    use    of    Burroughs    data    files    and    the 
passing    of    transactions    back    to    other    Burroughs 
applications.       The    stock    point    representatives    also    balked 
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at  the  massive  tape  processing  that  would  be  required  to 
implement  this  approach.   Without  these  other  application 
areas,  the  effort  required  just  to  do  batch  inquiries  and 
UH30  SUPERSCANs  on  anotner  host  could  not  be  justified. 

The  interim  capacity  task  group  finally  recommended  that 
a  combination  of  SPLICE  and  B4800s  could  handle  the  stock 
point  capacity  problem  until  SPAR.   In  the  interim,  SPLICE 
was  directed  to  come  up  with  applications  that  could  be 
"easily  downloaded"  with  high  payback  to  the  Burroughs  [Ref. 
47].   This  was  accomplished,  but  required  that  SPLICE 
implement  the  information  center  concept  discussed  above  to 
do  it,  despite  the  problems  [Ref.  48]. 

The  key  to  implementing  the  SPLICE  Information  Center 
was  to  find  a  mechanism  that  could  forward  images  of 
Burroughs  data  file  updates  to  SPLICE  in  real-time,  while 
minimizing  added  workload  to  the  Burroughs.   In  the  event 
that  workload  would  be  added  to  the  Burroughs,  it  had  to  be 
compensated  for  through  equivalent  environmental  or 
application  workload  removal.   The  problem  was  easily  broken 
into  pieces  for  analysis;  its  implementation  was  not  so 
easily  ace om pi i shed. 

The  real  time  passing  of  data  from  the  Burroughs  to 
SPLICE  could  physically  take  place  over  the  HY PE Re hann el ,  in 
a  manner  similar  to  that  planned  for  terminal  traffic. 
Therefore,  this  aspect  added  no  new  workload  to  the 
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Burroughs. 38   The  initial  load  of  REP  FILES  on  SPLICE  could 
be  done  from  normal  Burroughs  data  file  backup/recovery 
tapes,  therefore,  this  too  added  no  new  workload.   The  Navy 
Burroughs  environmental  mechanism  through  which  recovery 
images  of  data  file  changes  were  captured  on  disk  or  tape 
was  called  SCSP,  and  at  the  time  was  the  only  place  where 
"hooks"  could  be  incorporated  to  capture  data  file  updates 
images  for  SPLICE  " s imul tan eousl y" 39  with  their  update  on 
Burroughs.   However,  SCSP  was  already  believed  by  FMSO 
environmental  personnel  to  be  a  "system"  bottleneck  in  terms 
of  throughput,  therefore,  adding  an  additional  function  to 
SCSP  was  unthinkable. 40   Another  approach  was  required  in 
this  area.   This  aside,  the  SPLICE  resident  REP  FILE  and 
TRANSRECON  file  structures  and  update  programs  would  also 
have  to  be  developed,  but  as  a  wholly  SPLICE  resident 
process,  these  would  have  no  impact  on  the  Burroughs. 
Finally,  the  applications  to  be  "downloaded"  would  have  to 
be  developed  on  the  TANDEM,  again  with  no  negative 
processing  impact  on  Burroughs. 


38The  changes  required  in  SDCH  to  accommodate  the  SPLICE 
HYPERchannel  transactions  and  the  interface  Burroughs 
process  itself  to  the  HYPERchannel  are  additional  Burroughs 
workloads,  in  their  own  right. 

35SCSP  was  recommended  for  modification  to  perform  this 
function  by  the  FMSO  SPLICE  Project  office.   It  was  felt 
that  changes  here    would  be  most  transparent  to  application 
personnel.   Any  other  approach  would  (and  did)  require 
application  modifications. 

^^SCSP  also  has  other  functions  not  specifically  germane 
to  this  discussion  and  which  it  still  performs. 


The  final  solution  to  the  data  record  update  capture 
problem  required  all  Burroughs  application  programs  which 
made  disk  I/Os  to  be  recompiled  and  retested  using  several 
new  copy  routines.   The  incorporation  of  these  new  copy 
routines,  tied  to  a  new  Burroughs  environmental  program 
called  SREC,  permitted  the  relocation  of  the  update 
journal ing  function  or  TRANSRECON  process  to  be  selectable 
as  to  location.   At  a  non-SPLICE  site,  SREC  would  maintain 
Burroughs  resident  TRANSRECON  files  on  disk  or  tape  for 
master  file  reconstruction  purposes  and  End-of-Day 
processing.   At  a  SPLICE  site,  SREC  would  permit  the  passing 
of  the  TRANSRECON  images  to  the  Burroughs  HYPERchannel 
interface  module,  which  was  expected  to  interface  with  a 
Network  System  Corporation  Burroughs  Network  Executive 
(NETEX)  software  product  and  a  FDC  interface  product.   These 
images  would  be  sent  to  SPLICE. 

When  the  Burroughs  NETEX  package  failed  to  be  usable  in 
an  operational  environment,  FMSO  developed  and  implemented 
their  own  HYPERchannel  interface  between  the  TANDEM  and 
Burroughs  (i.e.,  TABU)  systems.   The  following  describes  the 
basic  REP  F I LE/ TRANSRECON  processes  using  TABU: 

1.  SREC  passes  a  SPLICE  directed  TRANSRECON  record 
through  the  Burroughs  side  of  TABU  and  the 
HYPERchannel  to  the  SPLICE  portion  of  TABU  and  the 
SPLICE  Complex  Manager; 

2.  data  is  posted  as  received  to  a  replicated  data  TANDEM 
en  try  sequence  file; 
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3.  this  raw  replicated  entry  sequence  file  data  is  read 
and  segregated  into  at  least  one,  and  possibly  up  to 
nine  Burroughs  Activity  Code  files  per  Burroughs  host; 

4.  the  appropriate  SPLICE  replicated  file  is  updated  with 
the  record  image,  if  it  is  a  data  file  update; 

5.  at  close  of  business,  activity  code  segregated 
TRANSRECON  files  are  closed;  TRANSRECON  files  are 
dumped  to  tape  and  forwarded  to  the  Burroughs  for 
further  process  i  ng . 

A  more  detailed  explanation  of  these  processes  in  available 

in  [Ref.  49]. 

These  SPLICE  replicated  files  are  essentially  exact 
duplicates  of  their  Burroughs  masters  or  at  least  contain 
exactly  the  same  data  as  that  which  would  be  used  to 
reconstruct  the  masters  if  they  were  lost.   The  files  being 
replicated  to  date  are  the  MSIR,  RDF,  Requisition  Status 
File  (RSF),  and  the  Demand  History  File  (DHF). 

Once  the  replicated  files  were  available  for  use,  FMSO 
application  personnel  were  able  to  download  and  implement  18 
different  informational  screens  previously  only  available  on 
the  Burroughs  for  SPLICE  terminal  inquiry  use  [Refs.  50  and 
51].   Additionally,  it  was  now  possible  for  significant 
numbers  of  batch  UH30  SUPERSCANS  and  UB54  Batch  Inquiry  runs 
to  be  directed  from  the  Burroughs  to  the  SPLICE  replicated 
files  using  ENFORM  based  inquiries.   Further,  these 
replicated  files  are  available  as  source  data  inputs  to 
other  SPLICE  processes. 41   Concerning  End-of-Day  processing 
using  the  SPLICE  TRANSRECON,  beyond  the  activity  code  split, 


^^Examples  are  the  SPLICE  ABE  or  TLOD  applications. 
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no  information  was  received  concerning  further  download  to 
SPLICE,  although  a  project  still  exists  to  do  this. 

The  major  benefit  that  REP  FILES  and  TRANSRECON  Offload 
provide  to  the  corporation  is  the  potential  for  freeing  up 
Burroughs  capacity.   This  capacity  can  be  used  by  stock 
points  for  other  business,  as  a  reserve  for  new  or  enhanced 
future  FMSO  Burroughs  applications,  or  as  a  survival  tool 
usable  while  awaiting  SPAR.   Several  less  major  benefits 
also  accrue:  decreased  response  times  for  terminal  inquiries 
using  replicated  files;  less  turn-around  time  for  reports 
directed  against  replicated  files;  a  user  and/or  programmer 
oriented  ad  hoc  report  capability,  not  present  on  the 
Burroughs;  and  the  ability  to  implement  other  SPLICE 
processes  requiring  master  file  source  data  using  the 
r epl ic  ated  files. 

The  question  of  the  need  and  potential  for  migration  of 
these  processes  to  SPAR  is  a  delicate  one.   First  consider 
need.   It  is  hoped  that  SPAR  receives  sufficient  funding  to 
obtain  all  required  stock  point  site  hardware  and  software, 
as  well  as  funding  and  time  to  perform  the  transition  of  all 
FMSO  and  critical  local  applications  and  interface  these  to 
non-SPAR  resident  required  interfaces  (e.g.,  NISTARS).   If 
so,  SPLICE  could  immediately  give  up  many  of  its  current 
functions  or  applications  and  concentrate  solely  on  SPAR 
telecommunications  issues.   In  light  of  the  current  Gramm- 
Rudman  balanced  budget  initiative  and  the  inability  of  other 
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similarly  large  ADP  projects  to  adequately  size  and  budget 
for  all  new  equipment  requirements  on  day  one,  particularly 
user  information  center  and  fourth  generation  language 
driven  requirements,  it  is  questionable  that  sufficient 
funding  will  be  forthcoming. 

The  ability  to  use  SPLICE,  a  sunk  cost,  to  absorb  some 
of  the  stock  point  inquiry  and  report  oriented  workload, 
particularly  during  transition,  should  not  be  discarded  too 
rapidly,  even  though  it  means  continued,  temporary, 
duplicate  data.   Therefore,  it  is  assumed  that  the  need  to 
retain  SPLICE  REP  FILES  and  TRANSRECON  Offload  will  exist  as 
SPAR  transition  funding  becomes  a  target  for  savings. 

The  potential  for  migration  of  these  functions,  which 
should  be  limited  to  the  SPAR  transition  period,  depends  on 
the  corporation's  willingness  to  develop  and  implement 
environmental  software  that  performs  functions  similar  to 
those  performed  in  the  new  Burroughs  copy  routines,  SREC, 
and  TABU.   If  so,  the  SPLICE  information  center  can  be  re- 
established and  the  SPLICE  TRANSRECON  function  possibly 
serve  as  a  forward/ bac kward  bridge  for  SPAR  transition. 

The  potential  for  migration  is  also  dependent,  however, 
upon  how  the  SPAR  transition  system  data  base  is  planned  and 
what  will  be  done  during  transition  to  applications 
expecting  inputs  currently  obtained  from  the  TRANSRECON.   It 
may  not  be  possible  to  replicate  the  transitioned  data  bases 
if  a  DBMS  is  used  during  transition.   No  references  could  be 
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located  on  how  non-recovery  functions  of  the  current 
TRANSRECON  process  would  be  handled  during  SPAR  transition. 
Until  the  SPAR  procurement  proposals  are  available  for 
inspection  and  a  transition  plan  is  documented  in  detail, 
further  comments  in  this  area  are  merely  speculation. 

The  final  area  that  will  be  addressed  is  how  REP  FILES, 
TRANSRECON  Offload,  and  the  SPLICE  Information  Center 
tactically  support  or  can  be  made  to  better  support  the 
proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies.   These 
initiatives  directly  support  and/or  is  supported  by  the 
following  SPLICE  project  objectives:  6,  7,  8,  10,  11,  12, 
19,  23,  28,  29,  32,  33,  34,  35,  45,  and  46. 

There  are  several  recommendations  the  authors  have  for 
possible  enhancements  in  the  REP  FILES,  TRANSRECON  Offload, 
and  the  SPLICE  Information  Center  areas  that  will  enable  it 
to  provide  greater  support  or  benefit  to  the  corporation: 

1.  Expedite  the  replication  of  (or  in  many  cases,  initial 
disk  load  of)  the  Management  List  -  Navy  (ML-N)  on 
SPLICE  and  provide  update  and  inquiry  programs  to 
support  it.   This  activity  had  previously  been  planned 
for  SPLICE  to  eliminate  programs  C-UB46,  C-UB47,  and 
C-UC91,  as  well  as  a  number  of  local  uniques.   When 
SPLICE  provides  shipboard  access  to  these  files  for 
inquiry,  the  use  of  this  on-line,  accurate  ML-N  would 
be  of  great  assistance  in  ensuring  the  accuracy  of 
requisition  stock  numbers  and  in  pricing  replenishment 
and  not-carried  shipboard  requisitioning  actions. 

2.  Request  NAVDAC  to  investigate  the  automation  and 
development  of  a  Master  Cross  Reference  List  (MCRL) 
file  and  application  on  SPLICE,  including  both 
updating  and  inquiry  programs.   The  resulting  system 
could  be  implemented  at  NSCs,  NARDACs  and  NARDAFs. 
Direct  shipboard  benefit  could  accrue  from  this 
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initiative    in    the    area    of    locally    matching    Federal 
Supply    Code    for    Manufacturer/Part    Number    items    to 
National    Stock    Numbers.       This    would    reduce    both 
procurement    leadtime    and    purchase    activity    workload. 
The    file    could    also    be    of    some    use    to    stock    point 
Technical    Personnel     for    "first    cut"    research    efforts 
on    non-standard    requisitions. 

3.  Investigate    the    incorporation    of    the    full    TRANSRECON 
processing    portion    of    End-of-Day    operation    directly 
into    the    SPLICE    Environmental    TRANSRECON    Splitting 
Process.       This    specifically    includes    the    functions 
performed    by    programs    H-UJ96    and    H-UJ97.       The 
functions    performed    by    these    processes    appear   more 
environmental     than    application    oriented    and    could    be 
done    "on-line"    during    the    current    splitting    process. 

4.  Replace    the    current    TRANSRECON    bulk    file    tape    passing 
between    Burroughs    and    SPLICE    with    a    HYPERchannel    on- 
line  bulk    file    transfer    capability,    including    direct 
interface    to    applicable    MAPS    scheduling    routines. 
Tape    processing    among    systems    is    error    prone    and 
requires   much    operator    Intervention    never    planned    for 
within    SPLICE. 

5.  As    a    longer    term    measure,    r e- inv est ig ate    the 
downloading    of    the    remainder    of    End-of-Day    processing 
and    other    Application    H    report    generation    to    SPLICE. 

a.  Considering    the    reduction    of    tape    handling    this 
would    result    in,    the    potential    reduction    in 
operator    costs,    the    direct    interface    to    DDA    that 
would    be    available    without    operator    intervention, 
the    ability    to    feed    other    SPLICE    on-line    processes 
directly    (i.e.,    TLOD),    and    the    ability    of    SPLICE 
to    absorb    such    transaction    splitting    and 
duplicating    workload    to    return    capacity    to    the 
Burroughs,    the    apparent    delay    in    implementing    (or 
no    plans    to    implement)    these    downloads    should    be 

r e-ev  al uated . 

b.  With  End-of-Day  on  SPLICE,  electronic  distribution 
of  the  Application  H  repetitive  reports  (e.g., 
1144,  Semi-annual  Stock  Status  Report,  etc.)  will 
be  possible  through  TRANSFER  client  servers 
locally  and  SPLICENe t/DDN  for  long-haul 
distribution.   No  such  capability  exists  on  the 
Burroug  hs . 

c.  Current  SPAR  Modernization  Strategy  [Ref.  52] 
calls  for  the  elimination  of  End-of-Day  processing 
in  its  current  form.   Taking  steps  now  to 
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eliminate  the  current  process  from  the  Burroughs 
by  moving  it  to  SPLICE  simply  reduces  the  required 
SPAR  transition  effort  required  later,  when 
resources  will  be  more  strapped  for  time. 

6.  When  SPLICENet  is  fully  functional,  investigate  the 
creation  of  a  user  library  of  SPLICE  User  Information 
Center  ENFORM  inquiries,  at  either  FMSO  or  FDC.   Such 
a  library  would  lesson  the  need  for  users  to  "re- 
invent the  wheel"  on  local  inquiries,  functions,  and 
reports  processed  against  replicated  files.   When 
implemented,  library  products  could  be  copied  or  file 
transferred  for  use  at  local  sites. 

7.  Implement  a  stock  point  9  Cog  Asset  Visibility  program 
using  the  SPLICE  REP  FILES  (i.e.,  MSIR).   Both 
individual  site  inquiry  processes  for  determining 
asset  status  and  a  network  oriented  process  which  • 
would  summarize  all  stock  point  asset  status  could  be 
im  pi emen  ted . 

This  concludes  this  section  on  REP  FILES  and  TRANSRECON 

processing.   The  Statistical  Location  Survey  application 

will  next  be  addressed. 


F.   STATISTICAL  LOCATION  SURVEY  (STATLOC) 

STATLOC,  previously  called  the  Inventory  Location  Audit 
Project  (ILAP),  is  a  SPLICE  stock  point  manag emen t/ qual i ty 
control  related  application  and  one  of  the  most  recent  to 
have  successfully  completed  prototype.   STATLOC  is  a  method 
to  validate  the  physical  location  of  items.   It  is 
accomplished  through  the  reading  of  bar  coded  location  and 
stock  number  labels  of  items  in  stated  inventory  locations, 
verifying  material  present,  and  comparing  the  results  of 
these  efforts  with  that  which  is  recorded  on  UADPS-SP  master 
records.   When  discrepancies  are  uncovered,  action  is  taken 
to  correct  records  or  restore  material  in  correct  locations. 
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The    benefits    that    STATLOC    is    expected    to    bring    to    the 
stock    points    include:     improved    warehousemen    productivity, 
improved    location/ inventory    record    accuracy;    the    elimination 
of    the    previous    card    oriented    location    survey    process;    and 
the    generation    of    previously    unavailable    management    reports. 
A    further    possible    benefit,    if    the    program    continues    on    its 
successful    track,    may    be    the    elimination    of    certain    annual 
wall-to-wall     inventory    requirements. 

The    current    SPLICE    STATLOC    system    is    based    upon    a 
similar    ILAP    system    developed    on    a    PDP-11/70    minicomputer 
and    prototyped    by    NSC    Norfolk.       STATLOC    was    transitioned    and 
enhanced    by    a    contractor    to    run    on    SPLICE    in    the    1984-1985 
timeframe    and    was    prototyped    at    NSC    Jacksonville    in    1985. 
Subsequent    to    the    prototype,    enhancements    were    undertaken    to 
eliminate    tape    handling    and    reduce    and    consolidate    the 
number    of    transactions    required.       The    enhanced    system    is    now 
being    implemented    at    all    NAVSUP    stock    points. 

The    STATLOC    process    begins    with    the    selection    and 
generation    of    a    range    of    survey    locations    to    be    validated. 
This    was    previously    done    solely    as    a    batch    process    on    the 
Burroughs    and    a    tape    of    1 ocat ion/ i tem    records    produced    and 
loaded    to    the    TANDEMs.       An    alternate    process    is    now 
available    which    provides    needed    survey    data    from    terminal 
input    using    the    replicated    SPLICE    MSIR    file    and,    thus, 
reduces    Burroughs    workload. 
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Once  the  1  oca t ion s/ i tern s  to  be  audited  are  selected  and 
available  on  SPLICE,  a  SPLICE  terminal  is  used  to  build  load 
files  to  facilitate  further  download  of  portions  of  the 
entire  audit  range  to  TELXON  701  portable  bar  code  reading 
microcomputers/scanners  carried  by  the  warehousemen.   This 
download  is  accomplished  via  TANDEM  host  software  and  the 
RS-232  asynchronous  port  on  the  TANDEM  terminal. 
Accountability  for  which  transactions  have  been  downloaded 
and  to  which  devices  is  maintained  throughout  the  process. 

After  the  TELXON  701s  are  loaded,  warehousemen  audit 
specified  locations,  barcoding  locations  and  verifying  that 
designated  items  are  present.   Discrepancies  are  noted  and 
corrected.   When  the  audit  process  is  complete,  the  data 
stored  in  the  TELXON  701s  is  uploaded  to  the  TANDEM,  again 
via  a  terminal,  where  it  can  be  reviewed  or  edited. 
Discrepant  data  is  reformatted  into  transactions  for  further 
Burroughs  processing  and  currently  passed  to  the  Burroughs 
via  tape.   New  bar  coded  location  and  item  labels  may  be 
generated,  as  well  as  mandatory  (e.g.,  new  item  and  location 
changes,  no  material  found,  material  found  and  MSIR  zero, 
etc.)  and  optional  (e.g.,  m i ssi ng /d amag ed  location  label, 
missing/  damaged  item  label,  etc.)  reports  produced. 
Further  information  on  STATLOC  processing  is  available  in 
[Refs  53  and  54]. 

The  residency  of  STATLOC  on  SPLICE  should  preclude  the 
need  to  migrate  it  to  the  SPAR  transition  environment. 
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However,    based    upon    the    decision    to    continue    or    eliminate 
REP    FILES    during    transition,    the    range    of    location    survey 
selection    process    may    have    to    be    taken    off    SPLICE    and 
returned    to    reside    solely    on    the    new    SPAR    hosts.       Remaining 
interfaces    should    not    require   migration    to    the    SPAR 
transition    environment,    as    they    can    be    accommodated    via    the 
SPLICE-SPAR    HYPERchannel     interface    or    can    be    easily   moved 
back    to    a    tape    interface.       STATLOC    will    require    replacement 
in    the    SPAR   modernized    UADPS-SP    system. 

STATLOC    tactically    supports    and/or    is    supported    by    the 
following    proposed    SPLICE    objectives:    6,    11,    12,    28,    29,    32, 
33,    35,    38,    41,    and    49. 

The    following    recommendations    should    be    evaluated    by    the 
LOGMARS/ SPLICE    projects    to    assist    in    the    further    attainment 
of   corporate/ pro j ec t    goals    and    objectives: 

1.  Investigate    the   download    of   additional    portions    (or 
all)    of    the    UADPS-SP    inventory    process    (Application    I) 
to    SPLICE    to    eliminate    card    processing,    increase 
warehousemen    productivity,    increase    inventory 
accuracy,    and    capitalize    on    available    LOGMARS 
processing    technology    impl emen tabl e    now    on    SPLICE. 

2.  When    available,    replace    the    Burroughs-to-SPLICE    output 
tape    interface    with    a    HYPERchannel    bulk    file    transfer 

i  nter f ace. 

3.  Investigate  the  interface  and  incorporation  of  radio 
frequency  terminals  with  bar  code  readers  directly  to 
SPLICE  processors  to  eliminate  the  need  to  upload  and 
download  data  to  remote  devices. 

4.  Plan  for  the  movement  of  the  current  TAL  process  which 
transfers  data  to  the  TELXONs  to  an  intelligent 
terminal,  such  as  a  PC  interfaced  to  SPLICE  or  a 
TANDEM  DYNAMITE  workstation.   Movement  of  this  code  to 
a  PC  based  interface  makes  the  remaining  STATLOC 
processes,  written  in  TANDEM  COBOL,  more  portable  as 
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well    as    making  the    PC-TELXON    process    usable    on    any 

host    that    a    PC  can    be    interfaced    to.      Task    maintenance 

of    the    revised  TELXON- i n tel 1 ig en t    terminal     interface 
to    FDC. 

5.       Investigate    the    eventual     replacement    of    the    TELXON 
devices    with    competitively    procured    lap-top   micros 
with    bar    code    readers.       Such    devices,    with    a    floppy 
disk    interface,    would    be   more    easily    interfaced    to 
intelligent    PC    workstations,    thus    eliminating    the    need 
to    develop    and    maintain    Navy    unique    environmental 
software    as    required    in    the    current    interface. 

This    concludes    the    discussion    of    STATLOC.       The    next 

SPLICE    application    to    be    addressed    is    TLOD. 

G.       TRANSACTION    LEDGER    ON    DISK    (TLOD) 

TLOD    is    an    application    that    can    easily    be    placed    either 
under    the    inventory   management    or    the    stock    point   management 
(quality    control)    functional    area.       This    is    because    the 
application    not    only    provides    a    capability    for    inventory 
managers    to    review    historical    events    for    their   material 
assets,    it    also    provides    quality    assurance    personnel 
increased    control    over    identifying    the    causes    of    and 
correcting    effects    of   material    gains    and    losses    which    result 
from    errors    in    material    management. 

The    TLOD    concept    is    simple:    have    available    for 
interactive    use,    a    one    or    two    years    history    of    a    stock 
point's    business    activities    or    transactions    (e.g.,    receipts, 
issues,    adjustment    actions,    closing    balances,    etc.).      This 
on-line    transaction    history    can    then    be    used    to    investigate 
processing    discrepancies,    particularly    those    which    result    in 
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inventory  accuracy  problems,  financial  adjustments,  or  for 
other  causative/explanatory  research  purposes. 

This  concept  was  implemented  at  least  three  times.   The 
first  time  was  a  FMSO  developed  and  released  Burroughs 
program  and  file  resident  version,  which  went  to  all  UADPS- 
SP  sites.   This  version  was  subsequently  enhanced  by  NSC 
Norfolk  personnel,  implemented  there,  and  given  to  other 
UADPS-SP  customers  who  might  desire  to  use  it.   This  second 
version  again  provided  for  Burroughs  file  residency  and 
program  process  i  ng . 

There  were  several  problems  with  both  of  these  prior 
Burroughs  TLOD  versions: 

1.  Burroughs  Host  dependence  -   This  resulted  in  two 
probl ems : 

a.  when  the  Burroughs  was  down,  causative  research 
stopped.   Although  this  could  be  tolerated  for 
short  periods  of  time,  the  worker  productivity 
loss  resulting  from  this  was  unacceptable. 

b.  long  response  times.   TLOD  was  not  considered  a 
"strategic"  application  to  stock  point  operations, 
in  that  it  had  few  mandatory  users.   This  resulted 
in  insufficient  processing  priorities  being 
assigned  to  it  to  get  acceptable  response  times 
and,  thus,  to  provide  for  worker  productivity. 

2.  lack  of  Burroughs  hardware  availability.   TLOD 
requires  additional  Burroughs  hardware  (i.e.,  a  great 
deal  of  disk  and  terminals)  that  was  not  immediately 
available  on  NAVSUP  contracts  or  that  would  only  be 
necessary  until  SPLICE.   This  latter  situation  made 
justification  for  this  hardware  very  difficult. 

3.  Due  to  the  inflexibility  of  the  Navy  Burroughs 
BRAM/HAM  accessing  methods,  inquiry  processing 
requiring  numerous  non-collocated  records  was  not 
efficient.   Also,  no  alternate  key  support  was 

av  ail  abl  e. 
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The    third    version,    called    SPLICE    TLOD,    was    developed    by 
FMSO    incorporating    the    Norfolk    improvements    as    well    as 
enhancing    the    system    overall     to    correct    the    above    problems. 
It    was    prototyped    along    with    SPLICE    itself    and    REP    FILES    at 
NSC    Jacksonville    in    the    fall    of    1984.       It    is    currently    being 
implemented    at    all    NAVSUP    stock    points. 

The    processing    scenario    of    SPLICE    TLOD    is    very    straight 
forward    [Refs.    55    and    56].       SPLICE    TLOD    begins    with    file 
transition    from    either    the    old    FMSO    or    Norfolk    Burroughs 
TLOD    systems    to    establish    a    SPLICE    TLOD    file    baseline. 
After    this,    daily    updates    are    applied    to    these    SPLICE 
resident    on-line    history    files    via    tapes,    which    are 
extracted    from    the    TRANSRECON    via    the    End-of-Day    processing 
string    on    the    Burroughs.       Once    this    is    completed,    users   may, 
at    will,    execute    a    series    of    nine    pre-defined    terminal 
inquiries    or    other    ad    hoc    inquiries    against    the    SPLICE    TLOD 
files    to    obtain    needed    information    to    perform    causative 
research.       Outputs    can    be    either    terminal    or    printer 
directed. 

A    second    pre-programmed    usage    of    SPLICE    TLOD    is    to 
accept    inquiry    requests    from    the    Burroughs    for    a    specific 
transaction    history    of    an    item    within    a   given    parameter 
range.       These    requests,    received    from    a    Burroughs    queue,    may 
be    passed    to    SPLICE    on-line    over    the    HYPERchannel    or    via 
tape    and,    when    processed,    result    in    a    printed    output    of    the 
requested    history.       The    printed    listing,    the    Manual     Research 
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Inventory  Listing,  is  then  forwarded  to  the  customer  and 
used  for  pre/ post- i nven tory  research. 

SPLICE  TLOD  files  are  purged  on  a  monthly  basis,  or  as 
desired,  removing  the  oldest  month(s)  or  as  directed  by  the 
users.   In  many  cases,  disk  availability  and  cost  will  oe 
the  controlling  factor,  as  it  was  in  the  decision  not  to 
mirror  SPLICE  TLOD  data  files. 

The  benefits  SPLICE  TLOD  provides  the  corporation  are 
numerous.   The  inventory  accuracy,  monetary,  and  customer 
support  benefits  provided  by  all  TLOD  versions  (i.e.,  being 
able  to  locate  misplaced  material  through  causative 
research)  are  obvious.   In  specific  reference  to  SPLICE, 
however,  SPLICE  TLOD  provides  one  of  the  means  to  assist  all 
the  stock  points  in  resolving  the  inventory  accuracy 
problem,  since  the  abundance  of  SPLICE  hardware  permits  this 
program  to  be  implemented  on  a  system  wide  basis.   Finally, 
SPLICE  TLOD  not  only  enables  users  to  research  specific 
problems,  but  also  permits  them  the  time  and  tools  with 
which  to  research  and  identify  systemic  problems. 

There  are  less  obvious  quantity  and  quality  aspects  to 
these  benefits  also.   SPLICE  TLOD  permits  users  real  time 
access  to  transaction  history  records,  thus  permitting  them 
to  process  more  causative  research  actions  in  a  shorter 
period  of  time.    SPLICE  TLOD  eliminates  the  need  for 
voluminous  paper  listings  of  transaction  history  to  be 
maintained.   Besides  its  ascetic  value,  this  paperless 
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aspect  of  SPLICE  TLOD  reduces  storage  requirements  and 
decreases  lost  user  productivity  in  paging  through  mountains 
of  listing  to  find  a  single  item  or  item  history. 

Moving  now  to  the  area  of  SPLICE  TLOD  migration  need, 
several  comments  are  germane.   First,  TLOD,  regardless  of 
the  version  being  discussed,  is  inherently  tied  to  current 
Burroughs  TRANSRECON  processing.   If  during  SPAR  transition, 
TRANSRECON  maintenance  and  processing  is  perpetuated  on  the 
new  SPAR  system  or  is  performed  on  SPLICE,  SPLICE  TLOD  will 
be  able  to  obtain  its  currently  required  input  and, 
therefore,  will  not  require  migration  to  the  SPAR  transition 
environment.   If  some  other  scenario  is  planned,  a  redesign 
of  SPLICE  TLOD,  perhaps  moving  it  back  to  the  new  host 
environment,  will  be  required.   In  the  SPAR  modernized 
environment,  SPLICE  TLOD  should  be  unnecessary,  as  its 
function  will  be  performed  by  new  processing  capabilities 
planned  for  this  functional  area. 

SPLICE  TLOD  currently  supports  and/or  is  supported  by 
the  following  proposed  SPLICE  objectives:  6,  7,  11,  12,  18, 
19,  23,  29,  32,  33,  34,  35,  41,  46,  and  50. 

Concerning  recommendations  for  further  beneficial 

enhancements,  the  following  should  be  evaluated  by  the 

SPLICE  TLOD  project  to  assist  in  the  further  attainment  of 

cor por a te/ proj ec t  goals  and  objectives: 

1.   When  economically  justified,  replace  existing 

Burroughs  TLOD  terminals  with  TANDEM  6530s,  PCs,  or 
IBM  compatible  devices  to  provide  greater  terminal 
f unc  t  ional i  ty . 
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2.  When  a  Bur ro ug hs- to- SPL I CE  HYPERchannel  bulk  file 
transfer  capability  is  in  place,  eliminate  tape 
passing  from  the  Burroughs  to  SPLICE. 

3.  Investigate  the  use  of  the  SPLICE  TRANSRECON  to 
directly  feed  the  SPLICE  TLOD  function.   This  may  be 
done  in  conjunction  with  the  download  of  End-of-Day 
processing  to  SPLICE,  particularly  the  download  of 
program  UA32  processing. 

4.  SPLICE  TLOD  is  one  of  the  few  SPLICE  resident 
processes  that  does  not  use  mirrored  files.   If  file 
re-loads  due  to  downtime  become  a  problem,  fund 
additional  disk  in  order  to  mirror  disk  and  make  the 
SPLICE  TLOD  function  Non-Stop. 

5.  Investigate  the  need  and  possibility  of  including 
other  SPLICE  application  history  transactions  in  the 
SPLICE  TLOD  data  base  (e.g.,  NISTARS,  NAVADS,  etc.)  to 
obtain  complete  transaction  history. 

This  concludes  the  discussion  on  SPLICE  TLOD.   The  final 

application  to  be  discussed,  UCEPS,  will  next  be  addressed. 


H.   UADPS-SP  CONTROLLED  EXCEPTION  PROCESSING  SYSTEM 
(UCEPS) 

UCEPS42  is  a  SPLICE  based  effort  designed  to  regain 

control  of  (primarily)  Burroughs  exception  processing  at  the 

stock  points,  while  simultaneously  modernizing  this 

processing  aspect  overall.   To  understand  the  purpose  served 

and  benefits  provided  by  UCEPS,  one  must  first  understand 

what  exceptions  are  and  how  they  are  currently  handled 

within  Burroughs  UADPS-SP. 


^^UCEPS,  although  sorely  needed  at  the  stock  points,  is 
a  splinter  project  salvaged  from  a  larger  plan  to  enhance 
demand  processing  overall  on  SPLICE  in  a  standard  manner. 
The  larger  plan  was  called  Application  C  Enhanced  (ACE). 
ACE  appears  to  have  been  deferred  due  to  higher  priority 
stock  point  initiatives  (i.e.,  SPAR). 
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UADPS-SP    is    a    combination    batch    oriented    and    on-line, 
time/volume    transaction    initiated    system.       When    executing    in 
either    mode,    there    are    frequently    occasions    when 
transactions    cannot    pass    programmatic    validations    and, 
therefore,    are    rejected    for    human    intervention.       In    the    case 
of   many    on-line    transactions,    validation    exceptions    are 
immediately    returned    to    the    user    for    correction.       If    not    an 
on-line    transaction    or,     in    some    cases,    if    an    on-line 
transaction    that    the    user    does    not    want    to    correct 
immediately,    these    "errors"    or    exceptions    to    normal 
processing    must    be    returned    to    the    user    in    some    other    manner 
for    correction    and    re-input. 

UADPS-SP    application    processes    have    four    options    to 
choose    from    in    these    cases:    1.    SPOOL    the    exception    as    a    card 
punch    file    to    disk;    2.    record    the    exception    on    the    RSF    and 
SPOOL    it    as    a    card    file    to    disk;    3.    place    the    exception    on 
the    TRANSRECON    for    punching    after    End-of-Day    processing;    and 
4.    record    the    exception    on    the    RSF    and    place    it    on    the 
TRANSRECON    for    punching    after    End-of-Day    processing. 
Regardless    of    the   method    used,    the    exception    cards   must    be 
punched    and    returned    to    the    user    from    Data    Processing    for 
correction    and    re-input. 

There    are    several    problems    with    all    of    these    approaches. 
If    the    exception    is    returned    to    the    user    on-line    (e.g.,    a 
card     image    placed    on    line    24    of    the    input    CRT    or    punched    at 
the    input    card    r ead er/ punc h )  ,    the    user    may    have    to    re-input 
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the  source  data  as  well  as  correct  the  error.   This  is  non- 
productive and  in  many  cases  requires  the  maintenance  of 
card  reader/punch  equipment.   The  user  can  also  lose  or 
"misplace"  the  exception  entirely,  potentially  suspending 
processing  or  eliminating  processing  on  the  transaction  that 
caused  the  exception. 

The  batch  mode  of  exception  processing  is  equally 
problematic.   Cards  have  to  be  punched,  requiring  the 
maintenance  of  obsolete  mainframe  card  equipment. 
Performing  card  operations  is  a  labor  intensive  process  in 
terms  of  operational  manpower  and  computer  resources  to 
perform  TRANSRECON/ End-o f-Day  processing.   Card  processing 
is  wasteful  of  time  in  returning  them  to  the  customer,  in 
making  many  times  minor  corrections  from  source  documents  no 
longer  held  at  the  workstation,  and  then  receiving  them  back 
from  the  customer  for  re- input.   During  this  correction 
process,  cards  also  have  a  tendency  to  get  damaged,  lost,  or 
misplaced,  which  again  may  suspend  or  terminate  transaction 
processing.43 

UCEPS  is  designed  to  address  all  of  these  problems.   The 
benefits  which  will  accrue  are  as  follows:  elimination  of 
obsolete  card  equipment;  controlled  access  to  and  processing 
of  exceptions  with  virtual  elimination  of  lost  records;  and 
decreased  time  to  receive,  correct,  and  turn-around 


'^^In  the  case  of  the  exceptions  that  are  recorded  on  the 
RSF,  there  are  procedures  to  reproduce  the  exceptions. 
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exceptions.   From  these  steps,  UCEPS  should  result  in 
earlier  problem  identification  and  greater  user 
productivity. 

The  design  of  UCEPS  is  explained  in  detail  in  [Refs.  57 
and  58]. 44   A  brief  explanation  of  proposed  processing 
follows  to  assist  the  reader  in  understanding  this 
appl i cation. 

The  key  to  developing  UCEPS  will  be  in  the  method  used 
to  forward  Burroughs  exceptions,  that  previously  went  just 
to  the  TRANSRECON,  to  a  new  SPLICE  resident  file  called  the 
Exception  Control  File  (ECF).   What  appears  to  be  proposed 
is  a  change  to  an  unspecified  Burroughs  copy  routine  "to 
send  the  exception  and  additional  information  across  the 
HYPERchannel  to  be  logged  to  a  disk  holding  device"  [Ref. 
59].   Once  on  this  SPLICE  holding  file,  another  UCEPS 
process  will  then  validate  the  exception,  primarily  as  a 
duplicate  check,  and  if  no  duplicate  exists,  place  the 
record  in  a  SPLICE  ECF  for  on-line  correction  by  applicable 
application  personnel  and  for  statistical  reporting. 

Associated  processing  improvements  also  to  be  provided 

i  ncl ude  : 

1.       on-line    inquiry    and    correction    of    entries    on    the    ECF. 
Exceptions    may    be    worked    as    groups    or    on    an    individual 
basis,    by    applications    area.       Corrected    exceptions 
will    be    forwarded    back    to    the    Burroughs    on-line    and 


^^Both    of    these    references    are    draft    documents, 
therefore,    final     processing    may    be   modified    as    a    result    of 
the    testing/development    process. 
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deleted    from    the    ECF    and    placed    in    an    appropriate 
history    file    (i.e..    Exception    History    File    (EHF)). 

a    narrative    explanation    of    exceptions    being    worked    to 
supplement    the    two    character,    often    cryptic,    codes 
currently    generated.       This    system    narrative    file    will 
also    be    supplemented    by    a    local    narrative    file    for 
site    specific    comments    and     instructions. 

a    re-cycle    capability    to    automatically    forward 
exceptions    back    to    the    source,    when    the    exception 
generated    was    due    to    a    time    related    file    condition    and 
the    only    exception    processing    required    is    re-input    at 
a    1 ater    d  ate  . 

UCEPS    file   maintenance    (e.g.,    history    purges, 
narrative    file    updates,    etc.). 

exception    report   generation    (e.g.,    audit    trail, 
statistical,    workload,    turn-around    time,    etc.). 


These    improvements    will     initially    be    available    to 
Application    C    (Demand    Processing)     programs,    then    to    nine 
other    Burroughs    applications.       SPLICE    resident    applications 
will    also    be    provided    "hooks"     into    the    UCEPS    files    so    that    a 
single    exception    system    will    be    available    for    all    UADPS-SP 
user    applications,    regardless    of    program    or    processing 
location. 

The    need    and    potential     for   migrating    the    functions    of 
UCEPS    to    the    SPAR    transition    environment    will     not    exist    if 
SPAR    will    allow    "environmental"    software    to    be    written    and 
called    by    applications    to    enable    them    to    pass    exception 
transaction    images    over    the    HYPERchannel     to    SPLICE,    so    that 
ECF    updating    can    continue    there.       If    no    environmental 
software    is    written    to    do    this,    UCEPS    will    have    to    be    re- 
designed   and    r e- impl emen ted    on    the    new    SPAR    hardware    prior 
to    transition    system    implementation.       Under    SPAR 
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modernization,  UCEPS  should  be  subsumed  by  new  SPAR  on-line 
transaction  processing  methods  and,  thus,  eliminated  from 
SPLICE. 

SPLICE  UCEPS  is  supported  by  and/or  supports  the 
following   proposed  SPLICE  project  objectives:  12,  19,  23, 
24,  29,  32,  33,  34,  35,  41 ,  and  45. 

There  are  several  recommendations  that  the  authors  have 
concerning  UCEPS  to  enable  it  to  provide  even  greater 
support  to  the  corporation: 

1.  Modify  the  same  copy  routines  used  to  accomplish 
SPLICE  TRANSRECON  Offload  to  accommodate  UCEPS. 

a.  At  a  site  where  the  TRANSRECON  is  being  maintained 
on  SPLICE,  modify  the  file  replicator  software  on 
TANDEM  to  place  exceptions  from  the  SPLICE 
TRANSRECON  onto  the  holding  file  that  is  the  input 
to  the  UCEPS  ECF.   This  eliminates   duplicate 
exception  images  having  to  be  sent  down  the 
HYPERchannel  to  SPLICE  (i.e.,  once  for  SPLICE 
TRANSRECON  Offload  and  once  for  ECF  input). 

b.  At  a  site  where  the  TRANSRECON  is  being  maintained 
solely  on  the  Burroughs,  optionally  do  not  record 
exceptions  on  the  TRANSRECON.   When  the  option  is 
taken  not  to  record  the  exception  on  the  Burroughs 
TRANSRECON,  send  the  transaction  down  the 
HYPERchannel  to  the  SPLICE  UCEPS  process.   If 
exceptions  are  still  to  be  recorded  on  the 
Burroughs  TRANSRECON,  do  not  implement  UCEPS 
without  a  thorough  Burroughs  capacity  study. 45 

2.  For  on-line  Burroughs  applications  which  return  errors 
immediately  to  the  user,  evaluate  the  need  to  place  an 


^^When  the  TRANSRECON  remains  on  the  Burroughs  and 
exceptions  are    written  to  it,  that  requires  Burroughs 
overhead.   If  this  is  done  AND  another  image  of  the  same 
exception  must  be  written  to  the  HYPERchannel,  that  adds 
additional  Burroughs  workload  which  is  not  being  compensated 
for  via  workload  off-load.   Prior  to  doing  this,  a  capacity 
study  for  the  site  must  be  undertaken  to  ensure  that  the 
benefits  from  implementing  UCEPS  will  outweigh  the  costs. 
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information-only  record  of  the  exception  on  the  UCEPS 
ECF  or  EHF. 

a.  In  some  Burroughs  applications  (i.e.,  Application 

N  UN50),  the  on-line  validation  programs  appear  to 
return  exceptions  to  the  input  terminal  based  upon 
the  terminal  mode  the  user  is  in  (i.e.,  in  frames 
mode,  to  line  24;  in  Roll  Down  Input  Top  (RDIT) 
mode,  to  the  top  of  the  screen).   Exceptions  may 
still  be  lost  here  due  to  user  error  or  if 
exceptions  roll  off  the  screen. 

b.  The  proposed  ECF  or  EHF  information-only  image  of 
the  exception  may  be  the  only  place  to  recover  the 
lost  exception  and  perhaps  the  entire  transaction. 

UCEPS  is  being  implemented  in  a  phased  approach, 
starting  with  Application  C.   Rather  than  continuing 
with  Burroughs  applications,  consideration  should  be 
given  to  next  developing  the  UCEPS  interface  to  other 
SPLICE  resident  applications,  particularly  those 
currently  in  design  or  development  (i.e.,  APADE  or 
SPLICE  ABE).   In  this  way,  UCEPS  interfaces  could  be 
implemented  while  the  application  is  under 
development,  vice  requiring  a  major  maintenance  action 
1 ater  .46 

Investigate  the  incorporation  of  other  system 
exceptions  into  UCEPS.   Specifically,  NISTARS  and 
NAVSCIPS  exceptions  should  be  considered. 

Do  not  let  the  successful  implementation  of  UCEPS 
become  the  only  portion  of  ACE  to  be  implemented  on 
SPLICE.   There  are  simply  too  many  benefits  available 
to  the  corporation  from  implementing  ACE,  particularly 
if  SPAR  transition  funding  is  curtailed,  to  permit  its 
demise.  At  a  minimum,  a  method  must  be  provided  to 
issue  material  and  generate  DD-1348-ls,  including  bar 
code  data,  on  the  SPLICE  system  using  the  replicated 
MSIR  as  the  source  when  the  Burroughs  is  down.   All 
such  issues  must  be  locally  recorded  on  SPLICE, 
without  changing  the  quantity  on  the  replicated  MSIR, 
and  transactions  collected  to  forward  back  to  the 
Burroughs  to  update  the  master  MSIR. 


^^This  recommendation  is  being  provided  because  in  no 
other  application  documentation  reviewed  for  this  thesis  was 
there  any  mention  of  an  UCEPS  interface.   Hopefully,  this  is 
merely  an  oversight. 
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These  recommendations  conclude  both  the  discussion  of 
UCEPS  and  this  chapter  on  centrally  developed  SPLICE 
applications.   The  next  area  to  be  addressed  will  be  locally 
developed  SPLICE  applications  and  their  support  of  corporate 
and  project  plans. 
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Y.  LOCALLY  DEVELOPED  SPLICE  APPLICATIONS 

A.   CHAPTER  OVERVIEW 

The  contagion  concept  described  by  Nolan  and  Gibson 
[Ref.  60],  also  referred  to  as  the  technology  learning  and 
adaptation  concept  by  Cash,  McFarlan,  and  McKenney  [Ref. 
61],  is  at  work  today  at  the  stock  points  who  have  received 
their  SPLICE  hardware.   Essentially,  both  these  concepts 
describe  a  phase  of  ADP  technology  infusion  where  users  have 
received  systems  to  perform  some  initial  tasks  and  have 
themselves  discovered  other  productivity  enhancing  tasks 
that  the  same  systems  can  also  perform.   When  users  have 
demonstrated  that  these  additional  endeavors  promise  high 
payback  for  minimal  investment  and  are  permitted  to  pursue 
them,  substantial  unexpected  paybacks  can  accrue  to  the 
organization.   Once  this  situation  is  identified,  it  is 
management's  job  to  exploit  these  paybacks  through 
organization  wide  dissemination  of  the  new  uses  for  the 
tec  hnol ogy  . 

This  chapter  deals  with  three  locally  developed  SPLICE 
applications  that  fit  this  mold.   All  three  were  implemented 
with  minimal  initial  investment  and  can  have  applicability 
across  all  stock  points.   The  authors  intent  in  describing 
these  initiatives  is  to  make  the  corporation  aware  of  these 
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"home  grown"  initiatives  on  SPLICE,  in  the  hope  that  they 
will  be  applied  stock  point  wide  to  attain  corporate  goals. 

The  first  application  to  be  discussed  deals  with  a 
TANDEM  based  Electronic  Transfer  of  Funds  (EFT)  application 
to  Federal  Reserve  Banks  (FRBs)  for  civilian  payrolls.   The 
second  local  unique  application  is  a  method  for  entering 
payroll  data  via  SPLICE  terminals  instead  of  punched  card  or 
non-standard  key- to- tape/ key- to-d i sk  systems,  as  is 
currently  done  by  the  many  of  the  stock  points. 47   jhe  last 
application  is  an  approach  to  interim  stock  point  office 
automation  that  has  been  successfully  prototyped  at  NSC 
Pearl  Harbor. 

B.   ELECTRONIC  FUNDS  TRANSFER  (EFT) 

EFT  is  a  very  expeditious  way  to  get  payroll  data  to  the 
regional  FRBs  for  further  distribution  to  employees'  direct 
deposit  accounts  at  designated  financial  institutions.   The 
Treasury  of  the  United  States  informed  all  government 
agencies  in  1983  that  EFT  is  the  preferred  method  of  making 
payment  of  recurring  benefit  and  salary  payments  through  its 
Direct  Depo s i t/ El ec tro n i c  Funds  Transfer  (DD/EFT)  program. 
[Ref.  62] 


'^  7 1 1  had  been  the  authors'  intention  to  also  address  the 
joint  NSCs  Norfolk/Pearl  Harbor  Source  Data  Automation  (SDA) 
project  using  SPLICE,  which  has  only  recently  been 
documented.   Unfortunately,  required  documentation  on  this 
initiative  was  not  received. 
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Under    DD/EFT,    a   disbursing    office    through    its    ADP 
processing    activity    sends    its    civilian   mechanized    payment 
data    to    the    local     servicing    FRB,    two    to    three    days    before 
each    payday.       The    data   may    be    delivered    on   magnetic    tape    via 
mail    or    courier,    or    transmitted    via    telecommunications    from 
the    submitting    activity.       The    FRB    will     strip    away    the 
payments   going    to    the    institutions    it    serves    and    then    send 
the    remainder    of    the    pay    data    to    the    FRB's    automated 
Clearing    House    for    further   dissemination    to    non-serviced 
institutions. 

Most    stock    points    are    taking    advantage    of    DD/EFT    today 
by    submitting    their    payroll     information    through   magnetic 
tape    sent    via   mail    or    couriers    to    the    FRBs,    since    the 
Burroughs    cannot    support    the    appropriate    protocols    to    send 
this    data    via    telecommunications.      There    are    several 
problems    with    this    approach,    however.       First,    the    batch 
oriented    non-Navy    standard    payroll    process    used    today    at 
stock    points    often    results    in    late    payroll    runs    or    re-runs. 
With    the    requirement    to    have    DD/EFT   data    to    the    FRBs    several 
days    before    a    required    payday,    any    problems    experienced 
processing    the    payroll    leaves    little    time    left    to    physically 
move    tapes    to    FRBs.       Secondly,    many    of    the    stock    points    are 
in    areas    that    periodically    experience    incapacitating 
weather.       In    such    cases,    delivery    of    tapes   might    also    be 
delayed.       Finally,    both    the   mail    and    courier    services    are 
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subject  to  holiday  workloads,  inadvertent  package  losses, 
and  theft . 

To  overcome  these  shortcomings,  NSC  Norfolk  has 
developed  a  DD/EFT  data  communications  transmission 
procedure  using  SPLICE.   The  procedure  is  simple.   Payroll 
data  on  tapes  from  Burroughs  Application  K  are  taken  to  the 
SPLICE  TANDEM  where  it  is  loaded  to  disk,  after  resolving 
the  data  format  inconsistencies  between  the  two  systems. 
Then  a  process  is  run  which  inserts  data  communications 
control  characters  in  the  data,  as  required  by  the  FRB.   To 
commence  data  transfer,  the  NSC  calls  the  FRB  to  request 
permission  to  transfer.   The  FRB  then  establishes  connection 
to  the  TANDEM  system  via  a  4800  bit  per  second  line.   When 
connection  is  established,  the  NSC  executes  a  TAL 
application  which  interfaces  to  the  TANDEM  ENVOY  data 
communications  software  and  sends  the  payroll  data.   After 
the  transmission  is  accomplished  the  FRB  will  call  the  NSC 
for  a  verification  of  the  number  of  records  sent  and  totals 
of  the  payroll  transmitted. 

The  SPLICE  TANDEM  system  configuration  required  to 
implement  this  application  is  equally  simple.   A  data 
communications  line  must  be  available  from  the  FRB  to  the 
TANDEM  and  configured  on  the  TANDEM  system  as  a  point-to- 
point  line  using  a  bisynchronous  protocol  provided  in  ENVOY 
and  connected  to  a  by te- sy nc hronous  controller.   All  of 
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these  components  are  available  from  the  SPLICE  contract. 
The  NSC  TAL  application  is,  obviously,  Navy  unique. 

The  benefits  to  the  corporation  from  this  simple 
application  at  NSC  Norfolk  are  threefold.   First,  there  is 
an  elimination  of  some  manual  operation  in  the  secure 
delivery  of  payroll  data,  which  should  result  in  some 
monetary  savings  (i.e.,  couriers).   Secondly,  since  its 
takes  less  time  to  physically  transmit  the  payroll  data, 
less  lead  time  is  required  by  Data  Processing  to  receive  the 
payroll  outputs.   This  time  differential  is  available  to  be 
used,  when  necessary,  to  accommodate  batch  payroll  process 
re-runs  or  late  runs.   And  thirdly,  the  system  has  been 
implemented  without  the  need  to  use  scarce  FMSO  CDA 
development  resources  and  is  now  available  to  other  stock 
po  ints  at  1 i  ttl e  cost . 

Concerning  migration  to  the  SPAR  environment,  the 
authors  believe  that  a  need  exists  to  have  a  similar 
facility  available  at  the  stock  points  during  both  phases  of 
SPAR.   During  the  transition  phase  of  SPAR,  SPLICE  can 
perform  this  function  for  customers  having  SPLICE  hardware 
and  in  behalf  of  customers  who  do  not.   One  would  assume 
that  SPAR  modernization  should  not  need  to  be  concerned  with 
this  requirement  in  that  the  Navy  Standard  Civilian  Payroll 
System,  NAVSCIPS,  is  assuming  the  payroll  processing 
requirement  from  UADPS-SP.   However,  as  will  later  be  seen 
in  Chapter  VI,  a  SPLICE  or  its  successor  system  will  still 
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be  required  to  perform  the  transfer  function,  unless 
NAVSCIPS  assumes  tnis  role  directly. 

The  last  area  that  will  be  addressed  under  this 
application  is  how  the  EFT  process  tactically  supports  or 
can  be  made  to  better  support  the  proposed  SPLICE 
objectives,  thereby  supporting  previously  presented 
corporate  and  project  goals  and  strategies.   The  EFT  process 
directly  supports  the  following  proposed  SPLICE  project 
objectives:  8,  9,  12,  15,  19,  27,  29,  32,  35,  and  35. 

To  better  achieve  these  objectives,  the  following 
recommendations  should  be  considered: 

1.  The  NSC  Norfolk  EFT  system  should  be  enhanced  to  use 
the  HYPERchannel  to  pass  the  outgoing  bulk  file 
payroll  data  from  the  Burroughs  to  the  SPLICE  system 
and  further  improved  to  eliminate  the  required  calls 
made  back  and  forth  between  the  stock  point  and  FRB. 
A  mutually  agreed  upon  security  system  with 
verification  and  automatic  call  back  could  accomplish 
this  second  suggestion. 

2.  The  enhanced  NSC  Norfolk  EFT  system  should  be 
designated  the  stock  point  standard  system,  and 
implemented  at  all  stock  points  within  local  data 
communications  range  of  FRBs.   NSC  Norfolk  will  remain 
lead  CDA  for  the  system. 

3.  Gateways  to  FRBs  at  the  SPLICE  sites  within  the 
vicinity  of  FRBs  should  be  established  so  that  other 
stock  points  can  also  pass  their  payroll  data  to  FRBs 
via  SPLICENet. 

4.  If  NAVSCIPS  fails  to  provide  similar  EFT  transmission 
capabilities,  the  SPLICE  EFT  system  should  be  used  to 
accomplish  this  function,  as  a  back-end  process  to 
NAVSCIPS. 

If  these  recommendations  are  implemented,  this  simple  local 

application  can  easily  be  made  to  be  the  standard  UADPS-SP 

DD/EFT  interface  to  the  FRBs  and  enable  the  benefits  that 
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NSC  Norfolk  receives  from  it  to  be  shared  by  all  stock 
po  i  nts . 

This  concludes  the  discussion  of  EFT  processing.  The 
next  local  application  to  be  addressed  is  the  NSC  Norfolk 
Payroll  Processing  System. 

C.   PAYROLL  PROCESSING  SYSTEM 

As  will  be  discussed  in  the  next  chapter,  payroll 
processing  within  the  Navy  today  is  performed  by  numerous 
"standard"  and  local  systems.   One  of  the  requirements 
common  to  each  of  these  systems  is  the  need  to  get  the  time 
and  attendance  (T/A)  data  into  the  processing  systems.   At 
many  stock  points  today,  this  is  accomplished  by  using  a 
myriad  of  no n- stand ard i zed  keypunch,  key-to-tape,  or  key-to- 
disk  systems.   At  the  NAVSUP  stock  points,  the  output  from 
these  processes  are  uniformly  fed  as  inputs  to  Application  K 
on  the  Burroughs  systems. 

Several  problems  result  when  standard  inputs,  in  this 
case  payroll  T/A  inputs,  must  be  generated  from  non-standard 
systems.   First,  a  proliferation  of  hardware  types  results 
making  support,  maintenance,  and  replacement  very  difficult, 
as  well  as  uneconomical.   Secondly,  multiple  software 
applications  to  assist  users  in  inputting  data  in  required 
formats  must  be  obtained,  maintained,  and  interfaced  to 
other  systems.   In  the  environment  we  face  today,  this 
directly  results  in  duplicate  and  unnecessary  software 
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development  and  maintenance  manpower  costs,  particularly  if 
input  requirements  change,  as  they  will  under  NAVSCIPS. 

The  Payroll  Processing  System  (PPS)  developed  by  NSC 
Norfolk  on  SPLICE  addresses  both  of  these  problems  and 
provides  as  a  very  efficient  way  of  getting  standard  input 
into  the  current  UADPS-SP  payroll  system  via  terminal  entry. 
This  system  is  applicable  to  UADPS-SP  payroll  processing 
today,  and  as  is  addressed  in  the  next  chapter,  will  be 
equally  applicable  after  the  implementation  of  NAVSCIPS  in 
late  1986  or  early  1987. 

The  NSC  Norfolk  PPS  process  is  started  by  a  program  on 
the  Burroughs,  that  when  called,  creates  and  downloads 
payroll  skeleton  payroll  records  to  an  unlabeled  tape.   The 
unlabeled  tape  is  then  taken  to  and  loaded  on  the  SPLICE 
system  by  a  program  called  PAYLOAD.   PAYLOAD  purges  the  data 
in  the  current  PPS  payroll  data  files  and  loads  the  skeleton 
records  in  their  place.   These  skeleton  records  are  then 
ready  for  terminal  update  by  the  payroll  department  using 
TANDEM  PATHWAY  screens  painted  specifically  for  this  update 
process  and  the  time/labor  cards  manually  completed  by 
empl oyees .  [ Ref .  63] 

After  the  payroll  department  has  completed  entering  all 
the  current  pay  period  data,  a  second  program,  called 
PAYCARD,  takes  the  input  data  and  generates  a  card  image 
file  which  can  be  dumped  to  tape  and  fed  into  the  Burroughs 
Application  K  payroll  process.   From  this  point  on  the 
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Burroughs    processes    the    payroll    data    as    if    it    had    been    input 
directly    to    it    via    cards. 

There    are    several    benefits    that    this    simple    application 
has    provided    NSC    Norfolk.       In    using    this    PPS    application    the 
NSC    has    eliminated    the    need    for    punched    cards    or    non- 
standard   key-to-tape    type    equipment    for    payroll;    only    the 
standard    SPLICE    equipment    need    be    used.      This    system    has 
eliminated    the    need    to    send    this    data    to    an    area    other    than 
payroll    for   media    change    (i.e.,    from    sheets    of    paper    to 
punch    cards)     and    input.       Keeping    the   data    within    the    payroll 
section    adds   more    security    (i.e.,    less    chance    for 
unauthorized    changes    or   data    loss)     to    the    system    and    permits 
the    payroll    clerks    themselves    to    input    the    payroll 
information    instead    of    wasting    time    having    to   manually 
prepare    forms    for    someone    else    to    use.      This    process    has 
also    permitted    errors    to    be    corrected    on-line    as    they    occur, 
instead    of    having    to    review    and    return    inputs    to    another 
section    for    later    correction.       Finally,    this    new    process 
permits   more    time    for    payroll    clerks    to    audit    payroll    data 
instead    of   merely    having    time    to    locate    keyed    errors    that 
result    from    the    card    generation    process    and    the    illegibility 
of    the    writing. 

PPS,    like    EFT   discussed    above,    should    not    pose    a    problem 
to    SPAR   during    its    transition    phase,    if    the    system    is 
uniformly    implemented    on    SPLICE    at    all    stock    points.       In    the 
event    it    is    not,    SPAR    will    face    the    replacement    or    interface 
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of    card    and    key-to-tape    or    disk    systems    to    the    new    hardware 
and    transitioned    programs.       In    that    NAVSCIPS    does    not 
directly    provide    for    the    input    of    T/A    data,    SPLICE    or    its 
successor    system,    appears    to    be    required    to    provide    this 
function    under    SPAR   modernization. 

The    final    area    that    will    be    addressed    is    how    PPS 
tactically    supports    or    can    be   made    to    better    support    the 
proposed    SPLICE    objectives,    thereby    supporting    corporate    and 
project   goals    and    strategies.      PPS    directly    supports    and/or 
is    supported    by    the    following    SPLICE    project    objectives:    9, 
12,    27,    29,    32,    33,    35,    and    36. 

Although    PPS    is    a    local     system,    it    has    the    potential     for 
use    stock    point    wide    and    providing    support    for    corporate 
goals    and    the    SPLICE    objectives    listed    above.      To    this    end, 
the    following    recommendations    are   made    concerning    PPS: 

1.  That    PPS    be   designated    as    the    standard    payroll    pre- 
processing   system    for    the    UADPS-SP    community    and 
implemented    system    wide    on    already    available    SPLICE 
equipment.       NSC    Norfolk    will    remain    CDA.       This   move, 
when    followed    by    similar    cardless    environment    and    SDA 
projects    (i.e.,    UCEPS    and    the    emerging    NSCs 
Norfolk/Pearl    Harbor    SDA    projects),    should    eliminate 
the    need    for    non-standard    source    input    equipment, 
support    applications,    and    interfaces    to    other    systems. 

2.  That    PPS    output    formats    be   modified    to    the    NAVSCIPS 
input    format    when    that    system    is    delivered    to    the 
field    and    serve    as    the    stock    point    standard    T/A    data 
input   mechanism    under    that    system. 

3.  That    in    the    interim    to    NAVSCIPS,    improvements    be  made 
to    PPS    to    enable    file    passing    between    SPLICE    and  the 
Burroughs    via    HYPERc hannel  ,    eliminating    the    need  for 
manual     tape    operations. 
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This  concludes  the  discussion  on  PPS.   The  NSC  Pearl 
Harbor  Office  Automation  initiative  will  be  addressed  next. 

D.   OFFICE  AUTOMATION  INITIATIVES 

Office  Automation  (OA)  can  be  defined  as  the  automating 
and  linking  of  nine  functions:  stand  alone  computing,  word 
processing,  graphics,  electronic  spreadsheets,  personal  data 
base  management,  personal  management  (i.e.,  calendars, 
telephone  directories,  etc.),  a  computer  with  communications 
capabilities  for  access  to  and  source  data  automation  of 
mainframe  applications  to  improve  efficiency,  and  a  window 
to  data  sources  both  internal  and  external  to  the 
organization  [Ref.  64].   To  a  great  extent  within  the  stock 
point  community,  OA  appears  to  have  been  left  as  a  local 
prerogative  in  the  interim  to  SPAR. 48   jhe  result  of  this 
has  been  a  concentration  solely  on  local  (i.e.,  command) 
word  processing,  using  whatever  money,  hardware,  and 
software  that  the  site  could  obtain  (i.e..  Productivity 
Enhancing  Capital  Investment  (PECI)  funds). 

Although  not  within  the  project  charter,  with  SPLICE,  it 
is  possible  to  develop  and  implement  a  standard  stock  point 
OA  function,  covering  all  of  the  above  processing  areas 
under  the  current  SPLICE  contract.   With  some  additional 


'^^This  is  a  conclusion  on  the  part  of  the  authors.   It 
is  based  upon  two  facts:  1.  there  is  no  OA  standard  hardware 
or  application  software  in  UADPS-SP,  and  2.  the  inventory  of 
the  stock  point  OA  stand  alone  equipment  includes  WANG, 
XEROX,  NBI,  and  IBM  (all  procured  locally). 
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efforts,  this  standard  interim  stock  point  OA  system  could 
be  made  to  interface  with  the  other  existing  major  OA 
initiative  within  NAVSUP:  the  ICP  system.   The  lead 
organization  for  this  effort  has  been  NSC  Pearl  Harbor 
(NSCPH) . 

The  NSCPH  Data  Processing  Department  analyzed  tne  nine 
OA  functional  areas  and  determined  that  all  of  these 
functions  could  be  provided  by  SPLICE  on  a  phased  basis 
using  an  integrated  micro  based  system  to  distribute 
functions,  instead  of  performing  all  these  functions  on  a 
mainframe.   In  Phase  I,  standardization  of  microcomputer 
hardware  and  software  would  be  undertaken,  to  perform  local 
word  processing,  data  base,  local  graphics,  spread  sneet 
calculations,  and  other  desired  personal  computing.   The 
second  phase  would  provide  for  local  site  shared  disk 
storage,  shared  text  files,  shared  peripherals,  interface  to 
the  TANDEM  hosts  for  multiple  host  access  and  source  data 
automation,  and  the  addition  of  E-MAIL.   The  third  phase 
would  provide  the  ability  to  share  the  documents  and  mail 
created  locally  with  other  users  using  the  same  products  on 
remote  systems  linked  by  telecommunications  and  to  achieve 
full  interoperability  through  DDN.  [Ref.  65] 

NSCPH  initiated  Phase  I  with  the  procurement  of  45 
TANDEM  DYNAMITE  microcomputers,  each  with  256KB  of  RAM  and 
dual  360KB  disk  drives.   These  microcomputers  are  IBM  PC 
compatible  and  were  selected  over  other  IBM  compatible  PCs 
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to  provide  for  dual  usage  of  these  devices  (i.e.,  as  PCs  and 
as  TANDEM  6530  terminals)  in  other  phases.   Most 
workstations  included  printers  for  single  workstation  use. 
Software  selected  included:  dBase  III,  Lotus  1-2-3,  and 
Multimate  Advantage.   The  former  two  packages  were  selected 
as  they  are  established  industry  leaders;  the  latter  for  its 
ease  of  use  and  support  for  the  IBM  Document  Content 
Architecture. 

The  second  Phase,  which  was  implemented  six  months 
later,  consisted  of  the  connection  of  the  DYNAMITE 
workstations  to  the  TANDEM  hosts  as  6530  terminals  using 
standard  TANDEM  point-to-point  protocols.   This  step 
enabled:  the  introduction  of  local  source  data  automation 
initiatives  from  these  terminals;  E-MAIL  using  TANDEM'  s 
TRANSFER/MAIL  product  between  departments;  49  and  the 
interfacing  of  other  PCs,  sharing  of  TANDEM  host  printers, 
and  the  exchanging  of  files  among  existing  DYNAMITE  PCs 


^^TRANSFER/MAIL  will  be  upgraded  to  the  new  TANDEM  PS 
Mail  product  in  the  near  future.   PS  Mail  is  a  software 
product  that  will  let  you  draft  memos  and  send  them  along 
with  other  documents  to  users.   PS  Mail  is  a  full  service 
electronic  mail  system  that  guarantees  delivery  of  mail  and 
interfaces  with  Tandem  653x,  IBM  327x,  and  asynchronous 
(TTY)  terminals,  personnel  computers,  and  Group  3  facsimile 
machines.   This  software  is  menu  driven  and  gives  both  full 
screen  display  and  on-line  help.  [Ref.  66] 
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using    TANDEM's    PC    LINK    software. 50       in    this    phase,    NSCPH 
also    planned    to    eliminate    its    Xerox    360    word    processing 
system  . 

The    final     phase,    which    will     be    implemented    in    the    near 
future,    will    consist    of    connecting    the    NSCPH    SPLICE    system 
to    the    DDN    via    SPLICENet^l    to    enable    users    to    access    other 
SPLICE    system    applications,    pass    data    or    files,    and    use    E- 
MAIL    to    converse    with    other    activities    on    SPLICE.       At    some 
point,    when    full    DDN    interoperability    is    provided    by    SPLICE, 
these    capabilities    are    expected    to    be    usable    in    interfacing 
with    NAVSUP    and    DDN    subscribers    using    standard    DDN    service 
protocols.       A    WANG    system    used    in    the    NSCPH    Joint    Personnel 
Property    Support    Office    would    be    eliminated     in    this    phase. 
[Ref.    68] 

In    the    opinion    of    the    authors,    the    NSCPH    plan    for 
implementing    OA    at    its    site    can    serve    as    the    basis    for    an 
interim    standard    OA    function    at    the    all    stock    points.      There 
are    several    areas    in    this    plan    that    require    further 
definition    and    others    where    improvements    can    be   made. 


50pC    Link    allows    users    to    do    the    file    interchange 
functions    with    the    TANDEM    hosts    or    each    other    while    using 
DYNAMITE    workstations    or    IBM    PC    compatible    computers.         It 
also    allows    the    IBM    PC    compatibles    to    emulate    both    Tandem 
6530    and    IBM    3270    terminals.    Any    document    created    on    a    PC 
can    be    loaded    up    to    the    host    and    then    shared    by    multiple 
users.       The    commands    to    do    these    functions    are    MS-DOS 
commands    so    user's    need    not    learn    new    commands    and    can    use 
the    TANDEM's   mirrored    disks    as    their    hard    disk.    [Ref.    67] 

51see    Chapter    VII    for    further    details    on    SPLICENet. 
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However,  the  basic  plan  appears  sound  for  an  interim  OA 
system.   These  areas  will  be  elaborated  upon  in  the 
recommendations  section  for  this  application. 

The  benefits  that  are  accruing  to  NSCPH  and  can  accrue 
to  the  corporation  if  this  basic  plan  were  adopted  at  all 
SPLICE  sites  are  as  follows:  increased  white  collar 
productivity,  decreased  paper  generation  for  own-site  and 
inter-system  mail  and  reports,  standardization  of  interim  OA 
initiatives  requiring  a  single  replacement  strategy  by  SPAR, 
and  reduced  telecommunications,  terminal,  and  peripheral 
costs  through  the  introduction  of  multifunction  workstations 
that  can  share  resources  and  SPLICENet. 

If  such  as  system  were  adopted  stock  point  wide,  the 
need  to  address  OA  functions  during  SPAR  transition  would  be 
eliminated.   SPLICE  would  be  available  to  fulfill  this  role 
until  the  SPAR  modernization  effort  were  sufficiently  along 
that  stock  point  OA  could  be  addressed  as  a  separate  issue. 
When  appropriate  for  SPAR  during  modernization,  it  could 
then  address  the  replacement  of  stock  point  OA  functions 
concurrent  with  addressing  SPLICE  replacement. 

The  final  area  that  will  be  addressed  is  how  Office 
Automation  tactically  supports  or  can  be  made  to  better 
support  the  proposed  SPLICE  objectives,  thereby  supporting 
previously  presented  corporate  and  project  goals  and 
strategies.   Office  Automation  directly  supports  and/or  is 
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supported  by  the  following  SPLICE  project  objectives:  1,  12, 

13,  14,  15,  15,  19,  23,  25,  29,  32,  33,  34,  35,  41,  and  45. 

There    are    six    recommendations    that    the    authors    have    that 

could     improve    this    application    to    increase    corporation 

benefit,    assuming    that    it    is    accepted    as    the    interim    stock 

point    OA    system.       These    are: 

1.       It   may    be   more    cost    effective    to    implement    local    area 
networks    (LANs)    of    PCs    instead    of    using    point-to-point 
data    communications    and    DYNAMITE    workstations. 
Consideration    should,    therefore,    be   given    to    using    the 
recently    announced    TANDEM    PC    LAN    interface    product    in 
lieu    of    the    current    NSCPH    connection   method    for    future 
implementations    not    using    DYNAMITE    workstations. 


Stand  ard  s 
processi  ng 
partic  ul ar 
intra- si  te 
format   may 
on    a    depar 
r  e  s  t  r  i  c  t  i  V 
documents 
M  u  1 1  i  m  a  t  e 
stored    for 
disks,    as 
processor 
moved    thro 
systems . 
should    be 


need    to    be    established    concerning    word 

document    storage    and    interchange    formats, 
ly    in    light    of    plans    to    move    documents 
and    inter-site.    The    standard    Multimate 
be    acceptable    for    all    PCs    using    Multimate 
tmental    system,    but    this    format    is    too 
e    outside    of    this    environment.       Storage    of 
in    Document    Content    Architecture    format,    a 
option,    is    recommended    for   documents    to    be 

later    revision    or    shared    use    on    TANDEM 
well    as    for    usage    by    the    TANDEM    word 
T-TEXT/PS    TEXT    and    for    those   documents    being 
ughout    the    SPLICE    system    or    to    other 
Document    Interchange    Architecture    format 
used    for    inter-system    interchanges. 


Gateways    will    need    to    be    established    for   documents 
being    sent    to    non-SPLICE    systems,    particularly    to    the 
ICPNet    E-MAIL    system    or    at    the    NARDACs    to    the 
SperryLink    system.       FDC    (or    TANDEM    through    FDC)     should 
be    tasked    to    develop    the    TRANSFER    client    servers    or 
other    processes    needed    to    transform    SPLICE    produced 
documents    stored    in    DCA/DIA    formats    to    both    of    these 
systems    and    incorporate    the    inter-net    transmission 
requirements    into    their    SPLICENet    proposal. 

The    NSCPH    proposal    does    not    address    standardization    of 
PC   graphics    packages    (beyond    LOTUS    1-2-3)    or    personal 
support    packages    such    as    calendars.       Standards    should 
be    established    for    all     software    products    to    be    used. 
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5.  If  the  NSCPH  proposal  is  accepted  for  corporate  stock 
point  use,  bulk  site  licensing  or  corporate  quantity 
purchases  should  be  pursued  to  generate  savings  over 
buying  PC  software  packages  individually.   Network 
system  discounts  should  also  be  pursued  in  that  both 
local  PC  networks  with  system  servers  can  be 
implemented  to  store  software  and  the  TANDEM  host 
system  itself  can  store  software  for  connected  PCs 
through  the  TANDEM  host  FILE  SERVER  software  package. 

6.  NAVSUP  itself  is  not  a  planned  SPLICE  site/user, 
although  it  will  probably  be  the  intended  recipient  of 
much  of  the  stock  point  E-MAIL  traffic.   Consideration 
should  be  given  to  implementing  a  small  SPLICE  office 
system,  based  on  the  TANDEM  EXT  system  at  NAVSUP 
headquarters,  and  tied  into  SPLICENet  through  the  FDC 
facility  at  Chevy  Chase.   At  a  minimum,  NAVSUP  should 
have  a  facsimile  machine  available  at  headquarters  so 
that  hardcopy  output  can  be  received  by  NAVSUP. 

This  concludes  the  discussion  of  the  OA  application. 

Before  the  area  of  SPLICE  related  financial  applications 
is  addressed,  one  additional  comment  concerning  locally 
developed  applications  must  be  made.   It  is  extremely 
important  that  NAVSUP  functional  and  SPLICE  personnel 
monitor  the  local  applications  being  developed,  such  as 
those  described  above,  for  possible  implementation  stock 
point  wide.   From  the  authors'  review  of  preliminary 
documentation  on  such  systems,  it  is  also  imperative  that 
standards  for  local  system  documentation,  development, 
maintenance,  lead  CDA  responsibility,  and  most  importantly 
data  naming  standards  be  established  and  mandated  for  use  in 
these  locally  developed  systems. 
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VI.  FINANCIAL/PROCUREMENT  APPLICATION  SUPPORT  THROUGH  SPLICE 

A.   CHAPTER  OVERVIEW 

This  chapter  will  address  selected  under  development, 
planned,  and  existing  applications  in  the  financial  services 
and  procurement/contracting  functional  areas,  as  well  as 
make  proposals  on  how  they  might  benefit  from  improved  use 
of  and  interfaces  with  SPLICE.   The  same  format  for 
applications  analysis  specified  at  the  beginning  of  Chapter 
IV  will  also  be  used  in  this  chapter. 

The  first  application  to  be  reviewed,  the  Automation 
of  Procurement  and  Accounting  Data  Entry  (APADE)  system,  is 
from  the  procurement/contracting  functional  area  of  UADPS- 
SP.   APADE  is  currently  under  development  by  FMSO  for  use  on 
SPLICE  hardware.   The  method  to  be  used  in  analysis  here 
will  be  to  review  the  existing  development  plans  for  the 
application  and  make  recommendations  for  improved  use  of 
SPLICE  capabilities  where  appropriate. 

The  second  section  deals  with  a  project  that  promises 
an  all  new  financial  and  accounting  system  for  the  Navy.   It 
is  designated  the  Integrated  Disbursing  and  Accounting 
Financial  Information  Processing  System  (IDAFIPS).   The 
perspective  to  be  used  in  this  presentation  is  that  of  the 
developers  and  how  they  see  the  system  being  implemented. 
The  authors  will  then  make  recommendations  on  how  this 
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system  can  be  better  supported  by  using  SPLICE  in  its  system 
integration  and  telecommunications  support  capabilities. 

The  third  section  concerns  a  system  that  has  already 
been  implemented  at  tne  Navy  stock  points  as  a  forerunner  to 
IDAFIPS.   The  system  is  known  as  the  Integrated  Disbursing 
and  Accounting  DX  Phase  11(B)  E.   It  should  be  noted  that 
this  system,  part  of  the  original  FMSO  Financial  Management 
Improvement  Program  (FMIP)  at  the  stock  points,  will  be 
replaced  in  the  future  by  the  standardized  version  of 
IDAFIPS  which  is  under  development  by  the  Navy  Comptroller 
Standard  Systems  Activity  ( NAVCOMPTSSA )  . 

The  final  section  is  also  financial  in  nature,  but  is 
more  limited  in  scope  then  the  previous  three.   The  fourth 
section  addresses  the  Navy  Standard  Civilian  Payroll  System 
(NAVSCIPS)  that  is  also  being  developed  by  NAVCOMPTSSA.   In 
this  area,  following  a  discussion  of  major  functions,  the 
authors  have  made  recommendations  on  how  NAVSCIPS  might  be 
better  implemented  within  the  stock  point  community  by  using 
SPLICE  in  some  of  its  interface  and  data  entry  roles. 

With  this  plan  of  action  mind,  the  discussion  of  the 
APADE  application  can  be  undertaken. 

B.   AUTOMATION  OF  PROCUREMENT  AND  ACCOUNTING  DATA  ENTRY 
SYSTEM  (APADE) 

The  Navy  Supply  System  cannot  afford  to  stock  all  the 

repair  parts,  material,  and  services  that  are  required  for 

its  efficient  operation  or  to  meet  all  customer  demands.   It 
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is  often  necessary  to  procure  items  and  services  on  the  open 
market.   NAVSUP  has  been  designated  responsible  for 
administering  the  purchase/contract  functional  area  and  uses 
a  Navy  Field  Contracting  System  (MFCS)  to  perform  this 
f unc  t i  on . 

Numerous  attempts  have  been  made,  both  centrally  from 
FMSO  and  at  local  activities,  to  automate  this  labor,  paper, 
and  time  consuming  function  using  a  variety  of  vendor 
hardware,  software,  and  applications.   [Ref.  69]  summaries 
many  of  these  efforts.   To  date,  none  of  these  efforts  have 
met  with  complete  success  and,  thus,  none  have  resulted  in 
system  wide  deployment  of  an  application.   Failure  to  make 
progress  in  this  area  has  resulted  in  much  of  the  continued 
criticism  of  the  entire  Navy  procurement  "system"  both 
externally  and  internally. 

From  the  second  "rising"  of  SPLICE  in  1979,  plans  have 
been  in  place  to  address  the  NFCS  support  area  via  hardware 
and  software  procured  by  the  SPLICE  project  and  application 
software  developed  by  FMSO.   Only  since  1984,  however,  has 
high  level  Navy  interest  to  do  this  become  evident  and 
commonplace,  apparently  resulting  from  the  Buy  Our  Spare 
Smart  (BOSS)  initiative  [Ref.  70].   The  new  APADE  system  is 
the  result  of  this  heightened  interest. 

Specifically,  APADE  will  provide  NFCS  activities  a 
standardized  ADP  hardware  and  software  system  which  can 
prov  id  e  : 


130 


1.  document    control; 

2.  management    and    buyer    support    information; 

3.  automated    document    preparation; 

4.  and    stand-alone,    collocated    host,    and    satellite    ADP 
proces  s  i  ng    support . 

The    underlying    concepts    being    used    by    APADE    to    implement 
these    capabilites    are:    1.    an    automated    "birth-to-death" 
document    control     system;    2.     integration    of   data    and    word 
processing;    3.    single    source   data    automation    with    location 
independent    process- to-proc ess    interaction;    and    4.    maximum 
use    of    interactive    processing. 

System    monitoring    within    APADE    will    begin    with    on-line 
requisition    input,    which    will    be    possible    both 
electronically    from    remote    systems    and    locally    from 
terminals    on    the    APADE    system    itself.       Monitoring,    tracking, 
and    automated    status    reporting    to    external     and    local     system 
users    then    is    possible    and    continues    through    the    entire 
technical    review    and    contracting    processes.       Assisted    by 
automated    support    tools,    APADE    users    can:    plan    procurements; 
prepare    solicitations,    purchase    orders,    contracts, 
amendments,    and    modifications    on    system    produced    standard 
government    forms;    and    interact    with    financial,    supply,    and 
administrative    processes    to    provide    updates    and    status.       An 
extensive    range    of   management    and    buyer    reports    are    planned 
for    automation    including    work- i n- prog  re ss    reports,    completed 
work    or    productivity    reports,    all    reports    required    by    law    or 
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regulation,  POA&Ms  for  individual  procurement  vehicles,  as 
well  as  an  ad  hoc  reporting  capability. 

The  FMSO  APADE  functional  design  document  includes  seven 
processing  areas  to  perform  the  above  functions  which 
include,  requisition  input/update  processing,  pre-award 
processing,  award  processing,  contract  management 
processing,  inquiry  processing,  report  processing,  and 
system  management  processing.   See  [Ref.  71]  for  detailed 
specifications.   A  phased  implementation  approach,  including 
a  prototype  system,  will  be  utilized. 

The  benefits  which  can  accrue  to  NAVSUP  from  successful 
implementation  of  the  APADE  application  within  NFCS  include: 

1.  reduced  procurement  administration  lead  time  and 
actual  overall  procurement  time; 

2.  increased  information  accuracy  and  management  control; 

3.  increased  NFCS  worker  productivity; 

4.  and  improved  interfaces  with  other  systems. 
Several  aspects  of  plans  for  implementing  APADE  on 

SPLICE  are  worthy  of  note  in  terms  of  increased  corporate 
support  and  supporting  higher  level  NAVSUP  planning 
initiatives.   First,  APADE  intends  to  maximize  system 
integration  efforts  by  providing  on-line  interfaces  to 
systems  such  as  UADPS-SP,  the  Shipyard  Management 
Information  Sy stem/ Ma ter i al  Management  (SYMIS/MM),  the 
NAVAIR  Industrial  Management  System  (NIMMS),  the  IDA 
systems,  and  the  Engineering  Data  Management  Information  and 
Control  System  (EDMICS)  [Ref  72].   Electronic  requisition 
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inputs  from  applicable  systems  are  necessary  to  reduce  the 
amount  of  re- keying  of  data  within  APADE  itself.   Electronic 
interface  to  EDMICS  appears  required  to  provide  buyers  the 
use  of  centralized  technical  data.    Automatic  electronic 
status,  reporting,  and  financial  transactions  from  APADE  to 
other  applicable  systems  also  appears  required  to  reduce 
buyer  time  lost  in  providing  manual  status  or  generating 
non- proc ur emen t  related  transactions  to  these  foreign 
systems. 

Secondly,  APADE  plans  to  make  use  of  state  of  the  art 
technology  for  system  user  input/output  devices.   PCs  are 
planned  for  use  as  multifunction  workstations.   These  PCs 
can  be  interfaced  to  the  SPLICE  TANDEM  hosts  as  TANDEM  6530 
terminals  either  through  TANDEM  provided  PC  LINK  software  or 
via  FDC  provided  third  party  TANDEM  terminal  emulation 
software.   In  terms  of  output,  laser  printers  will  be  used 
for  generation  of  contract  related  forms  and  high  speed  line 
and  remote  printers  for  management  reports.   No  plans  for 
support  of  card  input  or  output  are  evidenced. 

Finally,  APADE  appears  to  have  successfully  incorporated 
an  integrated  data  processing  and  word  processing  approach 
within  the  application.   Although  the  interface  details  are 
not  specified  in  the  documentation  reviewed,  the  same  APADE 
terminal  will  be  capable  of  using  TANDEM  data  processing 
facilities  under  PATHWAY/ENCOMPASS  (e.g.,  for  inquiries,  buy 
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status  updates,  etc.)  and  the  TANDEM  PS  TEXT/ T-TEXT/ PS  TEXT 
FORMAT  word  processing  facilities  for  document  preparation. 

Having  described  its  purpose  and  potential  benefits  to 
the  corporation,  the  APADE  application  can  be  now  analyzed 
in  terms  of  its  need  and  potential  for  migration  to  the  SPAR 
Project.   In  that  APADE  will  be  totally  SPLICE  resident, 
there  appears  to  be  no  need  to  migrate  it  to  the  SPAR 
transition  environment.   A  transaction  and  process-to- 
process  interface  between  SPLICE  and  SPAR  will  be  required 
immediately  so  that  electronic  inputs  to  APADE  and  status 
from  APADE  can  be  forwarded  to/from  transitioned  UADPS-SP  on 
SPAR  on-line.   However,  this  should  be  no  different  than 
that  required  in  SPLICE  ABE  or  for  SPLICE  terminal 
connectivity. 

In  that  SPAR  will  eventually  replace  all  SPLICE 
applications,  the  APADE  application  must  be  supported  under 
modernized  SPAR.   The  potential  for  moving  this  function  to 
SPAR  appears  good  in  light  of  increasing  emphasis  of  major 
hardware  manufacturers  to  provide  both  data  processing  and 
full  word  processing  capability  on  the  same  hosts.   However, 
in  that  the  TANDEM  data  and  word  processing  environments  are 
so  different  from  that  of  any  of  the  potential  SPAR  contract 
bidders,  a  complete  re-design  of  APADE  on  the  SPAR  hardware 
should  be  anticipated  at  the  end  of  its  life  on  TANDEM. 

The  final  area  that  will  be  addressed  is  how  APADE 
tactically  supports  or  can  be  made  to  better  support  the 
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proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies.   APADE 
directly  supports  and/or  is  supported  by  the  following 
SPLICE  project  objectives:  4,  5,  6,  7,  12,  13,  14,  15,  29, 
30,  31,  32,  33,  34,  35,  41. 

There  are  several  recommendations  the  authors  have  for 
possible  enhancements  to  APADE  on  SPLICE  that  will  enable  it 
to  provide  greater  support  or  benefit  to  the  corporation: 

1.  Develop  an  APADE  Hardware  Interface  Requirements 
Spec ificat ion) . 

a.  The  APADE  FD  indicates  several  on-line  interfaces 
to  SPLICE  that  SPLICE  does  not  currently  support 
or  for  which  SPLICE  has  been  unable  to  obtain 
approval.   These  include  Data  General  hardware  for 
EDMICS  support,  Honeywell  DPS-6  for  SYMIS/MM 
support,  and  Univac  1100  interface  for  Navy 
Laboratories  or  NIMMS  support. 

b.  Include  within  this  the  nature  of  the  connectivity 
required.   If  a  high  speed,  large  volume  data 
interface  to  a  collocated  processor  is  required 
(i.e.,  UllOO),  that  may  be  easily  accommodated, 
assuming  that  the  host  concerned  has  a 
HYPERchannel  interface.   If  terminal  or  data 
communications  interface  is  required,  that 
represents  a  different  problem  and  must  be 
addressed  separately.   If  multiple  system  terminal 
access  is  required,  that  is  yet  another  problem. 

c.  Include  which  of  these  systems  does/will  support 
X.25  and  DDN.   Support  for  either  may  make  long 
haul  interface  requirements  simpler  to  satisfy. 

2.  Develop  an  APADE  Software  Interface  Requirements 
Spec  i  f icat ion . 


a.   Assuming  the  issues  within  hardware  connectivity 
are  resolved,  the  application  level  interfaces 
among  these  systems  must  be  addressed  and 
specified.   Although  it  may  be  a  simple  matter  to 
forward  an  APADE  generated  status  transaction  to  a 
UADPS-SP  program  over  HYPERchannel,  there  may  be 
no  existing  application  on  a  DPS  6  running 
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4. 


5. 


6. 


SYMIS/MM  expecting  an  external  system  generated 
data  communications  status  input,  for  example. 

b.   Include  complete  input  and  output  formats  for 
transactions  to  avoid  later  confusion,  if  other 
than  standard  MILSTRIP  formats  are  required,  as 
the  documentation  reviewed  indicates. 

Investigate  the  need  for  a  direct  APADE  to  EDMICS 
interface  and  perform  a  cost  and  feasibility  study 
prior  to  implementation. 

a.  Does  a  need  really  exist  for  buyers  to  see  EDMICS 
drawings  and  specifications  on-line  at  their 
terminals,  or  will  it  suffice  to  have  technical 
personnel  print  applicable  documents  on  their 
independent  EDMICS  terminal  printers  and  attach 
them  to  the  hardcopy  procurement  request? 

b.  TANDEM  does  not  today  support  CAD/CAM/CAE  or 
graphics  applications  except  on  stand  alone  PCs. 
Unless  bit-mapped  graphics  streams  can  be  passed 
through  the  TANDEM  via  an  existing  protocol  or 
emulation  package  (i.e.,  SNAX,  TR3271,  EM3270, 
etc.),  through  an  application,  to  a  connected 
APADE  PC  workstation  with  graphics  capability, 
this  interface  may  not  be  possible. 

c.  Unless  the  EDMICS  system  is  a  planned  DDN  user, 
SPLICE  may  have  great  difficulty  getting  data 
communications  access  to  it. 

Investigate  the  use  of  TANDEM's  PC  LAN  interface 
capability  for  terminal  interconnection  at  all  sites, 
but  particularly  stand  alone  sites  such  as  Navy 
Regional  Contracting  Centers  (NRCCs).   In  that  APADE 
plans  to  use  PCs,  it  may  be  more  advantageous  to 
obtain  and  use  the  TANDEM  host/local  area  network 
interface  for  PCs  in  terms  of  cost,  speed, 
ob ta in i ng/ in stal 1 i ng  data  communication  lines,  and 
original  equipment  manufacturer  support,  than  to  use 
PC  LINK/EM6530PC  or  third  party  TANDEM  terminal 
emulation  software  and  the  TANDEM  6100  communications 
subsy  stem . 

Require  the  implementation  of  DDA  at  stand  alone  APADE 
sites  for  transaction  and  status  passing,  along  with 
the  planned  DDN  interface.   DDA  is  currently  not 
scheduled  for  NRCCs. 

Investigate  the  development  of  TANDEM  TRANSFER  or 
PS/MAIL  client  servers  to  distribute  reports  destined 
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for  NAVSUP  or  other  SPLICE  sites.   Such  servers  can  be 
easily  interfaced  to  PATHWAY  applications,  providing 
immediate  electronic,  paperless  report  distribution 
locally  or  over  SPLICE  Net. 

7.   Ensure  the  APADE  data  naming  conventions  remain 
consistent  with  both  NAVSUP  508  [Ref.  73]  and  the 
emerging  SPAR  standards,  to  ease  later  transition. 

This  concludes  the  discussion  of  APADE.   IDAFIPS  will  be 

the  application  to  be  addressed. 

C.   INTEGRATED  DISBURSING  AND  ACCOUNTING  FINANCIAL 
INFORMATION  PROCESSING  SYSTEM 

The  Integrated  Disbursing  and  Accounting  Financial 

Information  Processing  System  (IDAFIPS)  is  designed  to 

streamline  and  automate  the  Navy's  financial  management 

system.   The  purpose  of  IDAFIPS  is  to  provide  the  Navy  with: 

A  timely  and  accurate  performance  of  disbursing 
functions  and  the  updating  of  accounting  data  bases;  to 
interface  with  other  financial  and  supply  systems;  to 
generate  fiduciary  reports  and  provide  for  on-line 
inquiry  and  update;  to  validate  mechanically  input  data 
elements;  and  to  support  electronic  data  entry  at  field 
activities  and  the  financial  information  processing 
centers  ( FIPCs) .  [Ref.  74] 

The  system  is  comprised  of  five  subsystems,  which  are 

described  below. 

The  Integrated  Disbursing  and  Accounting  Financial 

Management  System  (IDAFMS)  is  the  primary  subsystem  within 

IDAFIPS.   The  main  purpose  of  IDAFMS  is  to  mechanically 

integrate  the  accounting  and  disbursing  modules  at  field 

level  activities  and  provide  a  standard  financial  management 

system.   This  system  will  also  fully  automate  the  bill 

paying  functions  for  the  Navy  at  the  field  level. 
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More  specifically,  IDAFMS  operates  as  follows.   Invoices 
received  from  vendors  will  be  passed  through  a  mechanized 
payment  certification  process  and  be  validated  against 
procurement  documents  input  previously  by  the  fund 
administrators. 52   jhe  system  will  also  automatically  take 
discounts  and  certify  the  invoices  to  be  passed  to  the 
disbursement  module  for  check  generation  and  then  onto  a 
report  generation  module  for  the  necessary  record  updates. 
In  addition  to  handling  bill  payment  processing  via  check 
generation,  the  disbursing  module  also  will  take  care  of  all 
the  allotment  accounting  and  disbursing  for  field  level 
claimants  ashore  using  0&M,N,  0&M,NR,  and  RDT&E  dollars. 

IDAFMS  will  be  implemented  at  13  regional  sites,  called 
FIPCs,  using  a  real  time  access  data  base  system.   All  FIPCs 
should  be  collocated  with  SPLICE  computer  sites.   The  data 
base  at  each  FIPC  will  be  accessible  through  remote 
terminals  for  on-line  updates,  as  well  as  for  batch  updates 
and  report  transfers.   The  IDAFMS  data  base  will  provide 
sufficient  information  to  meet  all  the  required  financial 
management  needs  of  the  Fleet  Accounting  Activities  (FAA's) 
serviced  by  the  FIPCs  and  all  that  is  required  by  the  FIPC 
itself.   Over  900  FAAs  will  be  supported  by  the  FIPCs. 


52if  properly  designed  and  interfaced,  APADE  could 
provide  these  inputs  directly. 
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In  summary  form,  IDAFMS  will  use  modern 
telecommunications  capabilities  to  provide  Navy  management 
with  data  for: 

1.  planning,  programing,  and  budgeting  resources; 

2.  executing  against  budgeted  resources; 

3.  effective  control  over  all  assigned  funds  for  which 
the  Navy  is  responsible; 

4.  and  timely,  complete,  reliable,  and  accurate 
financial  reports  for  internal  Navy  management  use 
and  for  external  agencies  and  authorities  (e.g., 
0MB,  Congress,  Treasury,  DOD). 

IDAFMS  system  features  include: 

1.  random  access  data  base  processes  located  at  the 
regional  FIPCs; 

2.  extensive  internal  control  requirements; 

3.  use  of  telecommunications  to  support  interactive 
terminals  and  computer- to-computer  exchange  of  data; 

4.  and  interfaces  with  other  IDAFIPS  subsystems.  [Ref. 
75] 

The  telecommunications  interfaces  for  IDAFMS,  and  most 
of  IDAFIPS  for  that  matter,  will  be  locally  provided  by  the 
selected  hardware  manufacturer  and  eventually  by  DDN  for 
long  haul  communications.   In  the  interim  to  having  a  DDN 
capability  or  interface,  land  lines  will  be  used  for  long 
haul  communications. 

The  second  subsystem  of  IDAFIPS  is  called  IDAFMS 
OPFORCES,  and  will  be  the  standard  Navy  operating  forces 
accounting  system.   IDAFMS  OPFORCES  will  work  closely  with 
and  through  the  IDAFMS  module.   IDAFMS  will  take  care  of 
effecting  the  IDAFMS  OPFORCES  accounts  payable  transactions 
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through  its  mechanized  bill  payment  certification  process 
and,  at  the  same  time,  report  to  the  Financial  Reporting 
System  (FRS)  module. 

IDAFMS  OPFORCES  is  to  provide  the  following  specific 
features : 

1.  an  integrated  accounting  and  reporting  system  for 
deploying  and  shore  based  Operating  Target  (OPTAR) 
holders; 

2.  one-time  source  data  capture; 

3.  mechanized  interface  with  other  IDAFIPS  subsystems 
to  eliminate  hard  copy  generation; 

4.  a  standardized,  highly  responsive  financial 
management  system; 

5.  a  single  data  base  with  daily  updates  and  report 
generation  and  on-line  inquiry  capabilities; 

6.  interactive  edit  and  validation  at  source  of  input. 
[Ref.  76] 

The  telecommunications  interfaces  to  implement  the 
IDAFMS  OPFORCES  system  have  not  been  determined  at  this 
time.   Since  a  reduction  of  hardcopy  transmission  is  one  of 
the  major  driving  forces  behind  IDAFIPS,  an  afloat 
telecommunications  transfer  system,  as  described  in  Chapter 
VIII  of  this  thesis,  warrants  serious  consideration. 

The  Financial  Reporting  System  (FRS)  is  the  third 
subsystem  of  IDAFIPS  and  it,  too,  depends  very  heavily  on 
interfaces  with  IDAFMS.   FRS  will  provide  the  vehicle  to 
accumulate  and  prepare  for  transmission  of  financial  data 
between  FIPCs  and  from  each  FIPC  to  the  next  higher  level  of 
command  it  reports  to.   It  is  designed  to  operate  on  the 
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IDAFMS  hardware  located  at  the  FIPCs  and  to  reduce  the  labor 
intensive  functions  of  today's  system  through  on-line 
interactive  processing,  while  eliminating  some  batch 
processing  techniques.   FRS  is  to  provide  the  following: 

1.  reporting  at  the  Department  of  the  Navy  (DON)  level 
as  specified  by  NAVCOMPT; 

2.  detail  expenditure  and  collection  data  for 
processing  by  the  Centralized  Expenditure/ 
Reimbursement  Processing  System; 

3.  reports  of  funds  expenditures  and  collections  at  the 
detail  transaction  level  to  Authorized  Accounting 
Activities  (AAAs); 

4.  automated  cashbook  processing  for  Disbursing 
Officers; 

5.  and  overseas  and  afloat  disbursing  officer 
reporting.  [Ref.  77] 

FRS  is  to  be  an  on-line  entity  that  will  increase  the 

timeliness  of  reports  and  provide  the  capability  for  higher 

commands  to  do  on-line  inquiry  of  specific  financial 

information  of  subordinate  commands.   It  will  also  reduce 

the  amount  of  hardcopy  reports  transmitted  between  commands 

through  use  of  an  IDAFIPS  telecommunication  network. 

The  final  subsystem  under  IDAFIPS  is  the  Claimant 

Accounting  Module  (CAM)  which  will  be  used  by  major 

claimants  to  process  and  summarize  accounting  data  received 

from  subordinate  commands,  via  the  IDAFMS  and  OPFORCES  :  _ 

modules,  for  summarized  reporting  to  higher  authority. 

Major  claimants  using  the  IDAFIPS  data  base  will  be 

permitted  to  do  on-line  inquiry,  update  of  files,  and  report 

generation.   Each  claimant  will  be  supported  by  one  of  the 
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thirteen  regional  FIPCs.  Since  many  of  the  major  claimants 
and  the  FIPCs  are  not  collocated,  claimant  interface  to  CAM 
will  be  via  telecommunications. 

In  order  to  provide  the  kind  of  service  that  is  to  be 
provided  by  IDAFMS  it  was  determined  that  a  stand-alone 
computer  system  for  each  FIPC  was  required.   A  dual 
configuration  of  Burroughs  B6900s  was  selected  with 
associated  B1900  remote  batch  term inal / pr i n ter  and  tape 
drives53  at  selected  sites.  [Ref.  77]   Now  that  a  computer 
system  has  been  procured,  the  keystone  to  making  the  IDAFMS 
system  work,  once  the  applications  are  developed,  will  be 
the  telecommunications  system. 

Since  nearly  all  of  the  reporting  of  financial 
information  in  the  past  has  been  by  hard  copy  or  magnetic 
tapes  and  these  methods  were  determined  to  be  inadequate  to 
implement  the  IDAFIPS  system,  a  large  telecommunications 
system  has  been  called  for  in  all  the  system  documentation. 
Unfortunately,  beyond  statements  that  DDN  will  be  used  in 
the  long  run  for  long  haul  communications  and  Burroughs 
Network  Architecture  (BNA)  will  be  used  in  the  short  run, 
the  details  as  to  what  will  comprise  this  IDAFIPS 
telecommunications  network  and  how  it  will  be  implemented 
were  not  available  at  the  time  this  research  was  being  done. 
In  light  of  this,  the  authors  would  like  to  explore  ways  in 


53it  should  be  noted  that  the  B1900  is  one  of  the 
systems  that  NAVSUP  was  eliminating  at  the  stock  points 
through  SPLICE. 
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which    SPLICE    could    provide    some    portion    of    the 
telecommunications    support    required    to    handle    the    sharing    of 
financial     information    at    the    stock    points    and    for    afloat 
units,    as    called    for    by    IDAFIPS. 

In    the    13    regional     areas    where    the    B6900's    will     be 
located    there    will    also    be    a    SPLICE    site    in    the    same 
vicinity,    if    not    in    the    same    computer    room.       Since    the 
majority    of    the    B6900's    will    be    located    at    SPLICE    sites 
(i.e.,    NSCs    who    are    FIPCs    or    NARDACs,    which    may    operate    the 
IDAFMS    hardware),    it    is    feasible    that    the    SPLICE    system 
could    perform    the    following    functions    at    IDAFIPS    sites: 

1.  passing    bulk    files    and    individual     transactions    from 
UADPS-SP/SPLICE    to    the    IDAFIPS    B6900s    through    use    of 
the    SPLICE    HYPERchannel     network.       Financial 
information    to    be    passed    would    include    that    which    is 
produced    as   material     is    purchased    (i.e.,    from    APADE    on 
SPLICE),    is    received    (i.e.,    from    ABE    on    SPLICE),    and 
is    requisitioned    from    the    stock    points    (i.e.,    from 
End-of-Day    processing    or    applications    E    &    F) .       Using 
such    a    facility,    the    SPLICE    system    would    also    be    able 
to    accumulate    financial    files   or   data    to    be    added 
eventually    to    the    IDAFMS    data    base,    in    an    off-line 
mode    (i.e.,    on    a    contingency    basis    when    the    Burroughs 
6900s    suffer    hardware    or    telecommunications    problems) 
and    forward    it    to    tne    Burroughs    6900s    to    be    processed 
at    a    later    time. 

2.  a   gateway    for    the    B6900's    to    the    DDN    and    thus    to    other 
FIPCs    and    SPLICE    sites    around    the    country.       This    would 
release    the    B6900's    from    having    to    use    capacity    or    a 
unique    FEP    to    accommodate    a    separate    DDN    interface    and 
would    reduce    Navy    host    access    charges    at    processing 

s  i  t  e  s  .  5  4 

3.  a  FEP  for  Burroughs  terminals  requiring  access  to  both 
UADPS-SP/SPLICE  applications  and  the  IDAFMS  modules  at 
stock    points.       Using    the    SPLICE    Burroughs    terminal 


^^Current  cost  estimates  for  a  host  connection  to  DDN 
range  between  $2000  to  $5000  per  host  per  month  [Ref.  78] 
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support  capability,  a  single  terminal  on  SPLICE  in  the 
hands  of  an  authorized  user  could  be  made  to  have  pass 
through  capability  to  eitner  the  UADPS-SP  or  IDAFMS 
Burroughs  systems  by  use  of  the  Burroughs  Pre- 
processor Module  to  UADPS-SP  and  a  similar  module  to 
be  developed  to  link  to  IDAFIPS. 

4.  a  connection  point  for  local  no n- Bur ro ug h s  terminals 
and  users  that  are  outside  the  immediate  FIPC  and  that 
require  (and  are  authorized)  access  to  the  IDAFMS  data 
base.   By  providing  this  service,  SPLICE  could  reduce 
terminal  procurement  costs  and  data  communications 
line  costs,  while  relieving  the  Burroughs  IDAFMS 
system  from  having  to  handle  some  of  its 
telecommunications  overhead. 

5.  an  alternative  to  procuring  Burroughs  B1900  RJE 
computers,  particularly  where  these  may  have  been 
planned  for  sites  already  designated  as  SPLICE  MAPS 
RJE  facilities. 

6.  the  interface  between  NAVSCIPS  and  IDAFMS,  eliminating 
the  need  to  pass  tapes  between  the  systems. 

7.  the  ICP  interface  to  IDAFMS,  using  the  SPLICE  sites  at 
these  activities  and  SPLICENet/DDN  to  pass  data  to  the 
SPLICE  site  collocated  with  the  regional  IDAFMS  host. 

8.  the  OPFORCES  interface  to  IDAFMS,  using  the  interface 
methods  proposed  in  Chapter  VIII. 

9.  the  NIMMS  UllOO  application  interface  to  IDAFMS,  if 
and  when  the  UllOO  HYPERchannel  interface  is 
authorized  . 

The  benefits  that  such  interfaces  would  have  to  the 

corporation  and  the  Navy  at  large  are  primarily  financial: 

reduced  telecommunications  line  and  DDN  host  connection 

costs;  reduced  terminal  procurement  costs;  and  reduced  tape 

handling  and  manual  intervention  costs.   Additionally,  space 

savings  could  accrue,  in  that  single  terminals  at  sites 

would  be  able  to  function  in  multiple  processing 

environments.   Finally,  a  means  to  accomplish  an  afloat  unit 
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interface  is  provided,  which  appeared  lacking  or  at  least 
undefined,  in  the  documentation  reviewed. 

The  final  area  that  will  be  addressed  is  how  IDAFIPS  and 
the  proposed  SPLICE  objectives  can  be  mutually  supportive, 
thereby  supporting  previously  presented  corporate  and 
project  goals  and  strategies.   The  IDAFIPS  efforts  directly 
support  and/or  are  supported  by  the  following  SPLICE  project 
objectives:  12,  15,  16,  19,  22,  25,  27,  and  34. 

Since  the  interfaces  proposed  here  between  IDAFIPS  and 
SPLICE  do  not  currently  exist,  there  is  currently  no  way  to 
migrate  them  to  SPAR.   However,  unless  the  Navy  wishes  to 
continue  with  the  awkward  and  antiquated  tape  passing  of 
financial  data,  some  methods  such  as  those  proposed  above 
should  be  adopted  to  interface  these  systems.   Whatever 
these  methods  are,  they  should  then  be  carried  forward  to 
the  SPAR  modernization  environment. 

There  are  several  recommendations  the  authors  have  for 
possible  enhancements  to  IDAFIPS  through  interfaces  to 
SPLICE  that  will  enable  them  both  to  provide  greater  support 
and  benefit  to  the  corporation.   These  are: 

1.  Investigate  the  use  of  the  SPLICENet/DDN  as  a  primary 
means  of  transferring  data  and  communicating  between 
FIPCS,  instead  of  separate  IDAFIPS  host  DDN 

inter  f ac  es . 

2.  Investigate  the  use  of  the  HYPERc hannel s  to  link  the 
B6900's  installed  at  the  FIPCS  with:  the  current 
Burroughs  and  SPLICE  systems  installed  at  the  NSC's; 
the  Burroughs,  SPLICE,  and  Univac  systems  at  the 
NARDACs;  and  the  IBM/SPLICE  connection  at  the  ICPs  to 
handle  the  transfer  of  the  required  financial 

i  nf ormat i  on . 
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3.   Investigate  the  use  of  SPLICE  to  provide  the 

terminal  connection  for  terminals  requiring  access  to 
both  Burroughs  systems  resident  at  the  stock  points 
and  FIPCs,  as  well  as  utilize  non-Burroughs  terminals, 
and  to  provide  for  shipboard  access  to  FIPCs  as 
outlined  in  Chapter  VIII. 

This  concludes  the  discussion  of  IDAFIPS.   The  next  area 

to  be  discussed  is  IDA  11(B)  E. 

D.   INTEGRATED  DISBURSING  AND  ACCOUNTING  DX  PHASE  11(B)  E 

The  IDAFIPS  system  discussed  above  is  the  long  range 
plan  for  financial  management  in  the  Navy.   Prior  to 
IDAFIPS,  NAVCOMPT  had  sponsored  several  prototype  financial 
and  accounting  systems.   One  of  these  systems  was  developed 
by  FMSO  and  deployed  at  various  NAVSUP  organizations, 
including  the  major  stock  points,  under  the  banner  of  FMIP. 
Although  deployed  at  these  activities,  the  FMSO  FMIP  systems 
will  be  phased  out  under  the  IDAFIPS  system.   The  exact 
timing  of  this  phase  out  at  the  Navy  stock  points  is 
uncertain,  however,  and  until  that  time  the  FMSO  developed 
FMIP  modules  must  be  supported.  [Ref.  79] 

One  of  the  modules  of  FMSO  FMIP  is  the  Integrated 
Disbursing  and  Accounting  Data  Exchange  Phase  II(B)E 
(IDA  II(B)E).   IDA  II(B)E  is  of  particular  interest  to  this 
work  in  that  it  is  a  transition  candidate  to  SPLICE.   As 
such,  it  must  be  carefully  moved  to  the  SPLICE  hardware  and 
interfaced  to  other  stock  point  processes  in  the  most 
efficient  and  effective  manner  possible. 
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The    goal     of    the    entire    FMSO    IDA    program    was    to 
substantially    reduce    the    time    it    takes    to    input,    process, 
and    output    financial    data    at    the    stock    points    and    through 
the    entire   disbursing    and    accounting    systems.       The    phases    of 
IDA    previous    to    II(B)E    accomplished    such    things    as 
redirecting    the    flow    of    hard    copy    source   documents    from    the 
Navy    Regional    Finance    Center    to    the    local    AAAs,55 
innovations    to    processes    that    controlled    payments    of   vendor 
bills    and    reimbursable    billings,    and    improving    check    issue 
capabilities    with   mechanization    of    associated    reports.       All 
of    these    improvements    were    accomplished    on    the    Burroughs 
mainframes    and    primarily    in    batch   mode. 

The    batch    orientation    of    the    Burroughs    hosts    precluded 
any    additional    efforts    at    permitting    on-line    user    access    to 
the    various    accounting    and    disbursing    files.       However,    to 
achieve    its   goal    of    timeliness    in    financial     processing,    IDA 
had    to    provide    for    on-line    and    interactive    access    to    some    of 
its    files.       Therefore,    it    was    necessary    to    off-load    many    of 
the    on-line/interactive    processes    to    another    host.       In    the 
absence    of    SPLICE,    PE    hardware    and    TAPS    software    were    used. 


S^An    AAA    (pronounced    as    "triple    A")     performs    official 
accounting    and    disbursing    functions    for   multiple    commands 
within    an    area,    mostly    due    to    the    fact    that    AAAs    have    ADP 
systems    available    to    them.       The    area    commands,    usually 
referred    to    as    Funds    Accounting    Activities    (FAAs),    retain 
the    legal    responsibility    for    their    usage    of    their    funds, 
with    the    AAA    recording    the    results    of    FAA    actions    and 
processing    payments    which    result    from    those    actions. 
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The    IDA    II(B)E    subsystem    focused    its    empnasis    on 
accounting    processes    at    the    AAAs    and    large    FAAs.       In    this 
phase,    selected    accounting    master    files    and    transactions 
were    to    be    extracted    from    the    Burroughs    hosts    and    made 
resident    on    PE    hardware    using    TAPS.       These    files    and 
transactions    were    then    to    be    accessible    by    AAA    and    selected 
FAA    personnel     for    immediate    update,    inquiry,    and    on-line 
error    correction.       Changes   made    to    the    off-loaded    files 
would    be    applied    to    the    Burroughs   master    files    on    a    nightly 
basis,    through    PE    file    extracts    and    batch    updating    on    the 
Burroughs    system.       Following    completion    of    all    other    batch 
financial     processing,    selected    Burroughs   master    financial 
file    updates    would    then    be    applied    to    the    downloaded    files 
on    the    PE    for    further    processing,    again    via    tape    extracts. 

Once    the    files    were    loaded    and    PE    application    systems 
written    in    TAPS/COBOL,    the    key    to    this    phase    was    providing 
on-line    PE    system    access    via    available    Burroughs    terminals. 
More    specifically,    through    the    use    of    a    FMSO    developed 
terminal     access    and    networking    package    (i.e.,    INS),    users 
with    Burroughs    terminals,    who    in    the    past    would    have 
prepared    financial     input    documents    for    key    punching    and 
batch    processing     in    Application    g56    on    the    Burroughs    could 
input    these    on-line    on    the    PE. 


5 ^Appl ic at i 0 n    G    is    the    Cost,    Allotment,    and 
Appropriation    Accounting    application    in    UADPS-SP. 
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The    users    provided    such    access    were    at    both    the    AAAs    and 
selected    FAAs.57      At    the    AAAs,    the    system    users    had    the 
capability    to    input    and    correct    financial     transactions    for 
their    activities    and    in    behalf   of    those    activities    not 
receiving    remote    terminals    in    an    on-line   mode.       The    FAAs 
could    only    access    their    own    files.       Other    normal    Application 
G    batch    UADPS    transactions    still     had    to    be    processed    on    a 
periodic    batch    basis    on    the    Burroughs. 58 

The    impact    of    this    system    is    that    for    the    first    time    the 
AAAs    and    FAAs    had    direct    access    to    the    accounting    files, 
giving    them    timely    accounting    and    financial     information. 
Additionally,    the    individuals    who    were    responsible    for 
transactions    could    input    them    themselves,    thereby    allowing 
immediate    error    correction    and    saving    the    time    required    for 
card    preparation    and    waiting    for    the    next    batch    process. 

The    Application    G    files    to    be    extracted,    downloaded,    and 
updated    by    the    transactions    entered    on-line    on    the    PEs    were 
the    Transaction/Exception    File,    Job    Order    Reference    File, 
Document    Control     File    (DCF),    Posting    File,    and    General 
Ledger    File.    [Ref.    80]      Outputs    from    Applications    E/F59 


S^The    criteria    for   determining    which    FAAs    received 
terminal    hardware    was    existence    of    sufficient    transaction 
volumes    to    justify    the    costs    of    terminals    and    printers. 

^^Appl ic ati on    G    type    updates    and    corrections    are 
normally    card    generated    and    run    in    batch   mode    on    the    late 
shift    about    three    times    a    week, 

5^Appl ic ati on    E    is    Financial     Inventory    Control     and 
Application    F    is    Stores    Accounting. 
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could  be  also  be  input  directly  into  the  DCF  processes  being 
executed  on  the  PEs.   Transactions  to  these  files  could  be 
recalled  and  corrected  by  the  operators  of  the  terminals 
anytime  during  the  day. 

Where  then  does  SPLICE  fit  into  IDA  II(B)E?   Following 
stock  point  wide  implementation  of  the  system,  capacity, 
response  time,  and  hardware  problems  plagued  the  PE  and  TAPS 
based  systems.   Once  users  became  dependent  on  the  system, 
these  problems  were  unacceptable,  and  in  the  case  of  late 
vendor  payments,  costly  in  terms  of  missed  discounts  and 
interest  or  penalty  payments.   Although  optimization  efforts 
were  continually  undertaken  by  FMSO  personnel  to  improve 
performance,  three  inescapable  facts  remained:  the  PE 
systems  had  no  backup;  they  could  not  share  resources  in  the 
event  of  minor  failures,  and  there  was  limited  surge, 
reserve,  or  expansion  capability.   SPLICE,  then,  was  to 
resolve  these  problems. 

As  was   mentioned  in  Chapter  IV  concerning  NAVADS,  the 
transition  strategy  from  PE  IDA  II(B)E  to  SPLICE  IDA  II(B)E 
is  to  keep  the  transition  as  transparent  as  possible  to  the 
application  by  porting  TAPS,  in  its  updated  TAPS  II  PASCAL 
form,  to  the  SPLICE  TANDEM  system.   Transition  to  SPLICE 
should  only  require  current  TAPS  screens  to  be  re  implemented 
in  TAPS  II,  files  moved  to  TANDEM  ENSCRIBE  format  and 
interfaced  to  TAPS  II,  programs  re-compiled  into  TANDEM 
COBOL  and  interfaced  to  TAPS  II,  and  terminal  device  and 
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security    functions    placed    under    the    control    of    the    FDC's 
SAS/TMAP    processes. 

As    was    also    previously    indicated,    the    performance    of 
TAPS    II    on      TANDEM    is    poor    today,    and    there    are    questions    as 
whether    sufficient    optimizations    can    be   made    to    make    it 
usable    in    a    production    environment.       The    alternative, 
however,    would    be    a    complete    re-design    of    the    current    system 
into    the    TANDEM    native   mode    TPS    using    PATHWAY    and    ENCOMPASS, 
prior    to    any    usage    on    SPLICE.       Economic    justification    of 
this    alternative    would    be   difficult    and    would    require 
continued    PE    and    TAPS    support   during    the    duration. 

The    transition    of    PE    IDA    II(B)E    to    SPLICE    will    provide 
the    corporation    three    of    the    four    benefits    that    PE    NAVADS 
transition    to    SPLICE    did:    a    reduction    in    non-SPLICE 
minicomputer    system    support;    non-stop    support    for    the 
accounting    function;    and    a    reserve,    expansion,    and    growth 
capability    for    the    application.       See    the    NAVADS    benefits 
paragraphs    in    Chapter    IV    for    further    elaboration    on    these 
po  in ts . 

Assuming    the    transition    of    IDA    II(B)E    to    SPLICE,    there 
is    no    need    for   migration    of    IDA    II(B)E    to    the    SPAR 
transition    environment.       The    SPLICE    terminal    and    process-to- 
process    interfaces    to    SPAR    will,    however,    also    be    required 
to    interface    to    the    other    host    Application    G    processes    that 
will    be    transitioned    in    their    current    form    to    the    new 
hardware.      When    SPLICE    is    replaced    by    modernized    SPAR,    the 
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SPLICE  portion  of  IDA  II(B)E  should  not  require  migration, 
in  that  IDAFMS  should  be  implemented  at  the  stock  points  by 
that  time. 

The  final  area  that  will  be  addressed  is  how  IDA  II(B)E 
tactically  supports  or  can  be  made  to  better  support  the 
proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies.   IDA 
II(B)E  directly  supports  and/or  is  supported  by  the 
following  SPLICE  project  objectives:  12,  15,  16,  19,  22,  25, 
27,  and  34. 

The  following  recommendations  should  be  evaluated  by  the 
IDA  II(B)E  and  SPLICE  projects  to  assist  in  the  further 
attainment  of  corporate  and  project  goals  and  objectives: 

1.  When  IDA  II(B)E  is  implemented  on  SPLICE,  replace  the 
current  tape  file  uploads  and  downloads  with  a 
HYPERchannel  bulk  file  transfer  interface. 

2.  Ensure  that  SPLICE  IDA  users  are  afforded  Burroughs 
Pr e-P roc e s sor  access,  to  enable  them  to  use  other 
Application  G  Burroughs  screens  updates  and  inquiries 
from  their  SPLICE  based  terminals. 

3.  Investigate  the  use  of  SPLICE  to  provide  the  other 
FAAs  IDA  II(B)E  access  through  use  of  dial- in  lines 
and  intelligent  terminals/PCs  using  a  TANDEM  or 
Burroughs  terminal  emulation  package. 

4.  When  economically  justified,  replace  the  less 
functionally  capable  Burroughs  terminals  with  either 
TANDEM  or  IBM  3270  series  terminals. 

5.  Investigate  the  distribution  of  IDA  II(B)E  local 
management  reports  via  TANDEM  TRANSFER  or  PS  Mail, 
thus  reducing  hardcopy  and  paper  requirements. 

6.  Develop  a  plan  to  transition  the  IDA  II(B)E 
application  off  TAPS  II  entirely  to  native  mode  TANDEM 
PATHWAY/ENCOMPASS. 
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7.  If  additional  Burroughs  capacity  relief  or  downloads 
are  desirable,  investigate  the  download  of  IDA  IIA  to 
SPLICE.   There  appears  nothing  in  this  subsystem  which 
mandates  its  processing  on  the  Burroughs.   If 
accomplished,  this  would  return  capacity  to  the 
Burroughs,  improve  the  stock  point  check  issue  and 
disbursing  reports  facilities,  is  a  natural  co- 
process  to  the  SPLICE  APADE  application  for 
procurement  initiation  and  SPLICE  ABE  for  receipts, 
and  will  reduce  SPAR  transition  requirements. 

8.  If  it  appears  that  the  IDAFIPS  implementations  at  the 
stock  points  will  be  further  delayed,  investigate 
interim  interfaces  between  FMSO  IDA  (i.e..  Burroughs 
and  SPLICE  resident)  and  IDAFIPS  using  SPLICE  systems 
as  the  gateway  for  terminals,  processes,  and  file 
transmissions. 

This  concludes  the  discussion  on  IDA  II(B)E.   The 

NAVSCIPS  interface  will  next  be  addressed. 


E.   NAVY  STANDARD  CIVILIAN  PAYROLL  SYSTEH  (NAVSCIPS) 

The  NAVSCIPS  is  to  be  the  standard  DON  payroll 
processing  system.   The  Navy  currently  has  seven  "standard" 
and  four  unique  systems  to  pay  civilian  employees,  emanating 
from  multiple  CDAs  and  local  activities.   The  Navy  is  the 
only  service  that  has  not  implemented  a  single  standard 
payroll  system  and  to  correct  this  shortcoming,  NAVCOMPT  has 
chosen  NAVCOMPTSSA  as  the  CDA  to  de^velop  NAVSCIPS  and 
directed  that  it  be  implemented  Navy  wide. 

NAVSCIPS  is  to  be  located  and  operated  at  designated 
FIPCs  and  Financial  Processing  Centers  (FPCs),  many  of  which 
will  be  collocated  with  SPLICE  sites.   NAVSCIPS  must 
interface  with  other  existing  systems  as  well  at  these  and 
other  remote  sites.   The  need  for  existing  system  interfaces 
stems  from  a  nebulous  requirement  for  major  claimants  to 
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develop  "interface  programs  required  to  provide  standard 
inputs  and  process  standard  NAVSCIPS  outputs"  [Ref.  81]. 60 
The  following  other  Navy  information  systems  are 
specifically  designated  as  requiring  a  NAVSCIPS  interface: 

1.  IDAFMS 

2.  SYMIS 

3.  Standard  Automated  Financial  System  (STARS) 

4.  Naval  Ordnance  Management  Information  System  (NOMIS) 

5.  NAVAIR  Industrial  Financial  Management  System 
(NIFMS) 

6.  Navy  Civilian  Personnel  Data  System  (NCPDS)  [Ref. 
82] 

It  should  be  noted  that  no  NAVSUP  system  interface  is  called 

for,  leaving  both  the  NAVSUP  T/A  source  data  capture 

requirement  and  the  NAVSCIPS  output  to  NAVSUP  input  process 

problems  unaddressed. 

Having  received  T/A  inputs  from  these  other  systems, 

NAVSCIPS  will  provide  standard  and  enhanced  pay  processing 

features  and  capabilities  such  as: 

1.  complete  validation  of  T/A  and  record  maintenance 
inputs; 

2.  identification  of  missing  T/A  records  for  a  period; 

3.  automated  pay,  leave,  and  time  history  records; 

4.  automated  retroactive  pay  and  leave  processing; 

5.  an  automated  document  control  system; 


^Oyhe  best  information  that  the  authors  could  obtain 
indicates  that  the  inputs  are  T/A  data  from  other  system 
mechanized  processes  or  source  data  automation  efforts. 
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6.  automated  maintenance  of  the  SF  2806  Retirement 
Record ; 

7.  standard  interfaces  with  financial  management 
information  systems  and  the  NCPDS; 

8.  some  reconciliation  of  pay  to  labor  data; 

9.  automated  management  reports  on  overtime  and  leave 
usage ; 

10.  and  a  report  generator  capability.  [Ref.  83] 

The  Navy  chose  a  PE  3210  system  as  its  standard  hardware 

suite  for  NAVSCIPS,  obtained  from  the  Navy  Minicomputer 

Contract  with  C3,  Inc.   NAVCOMPTSSA  sizing  efforts  have 

indicated  that  a  larger  computer  than  the  PE  3210  will  be 

required  for  NAVSCIPS  at  (at  least)  five  of  the  required 

implementation  sites.   No  indication  of  how  these  larger 

systems  will  be  procured  has  been  provided.   The  main 

applications  programs  supporting  NAVSCIPS  will  written  in 

COBOL  or  FORTRAN,  using  the  SEED  data  base  management  system 

and  supporting  development  tools.  [Ref.  84] 

The  foreign  system  interfaces  to  NAVSCIPS,  both  in  terms 

of  input  and  output,  are  loosely  stated  by  the  CDA  to  be 

magnetic  tape  and  hardcopy  or  computer  formatted  reports. 

Within  NAVSCIPS  itself,  terminal  entry  will  be  the  major 

source  of  input,  with  terminals  connected  to  the  NAVSCIPS  PE 

d  i  r  ec  tl  y  . 

There  are  three  areas  where  the  integration  of  NAVSCIPS 

and  SPLICE  at  the  stock  points  sites  could  be  of  benefit  to 

the  corporation.   First  using  the  NSC  Norfolk  local  SPLICE 

PPS  discussed  in  Chapter  V,  SPLICE  could  develop  a  standard 
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T/A  input  process  to  NAVSCIPS  for  use  at  all  stock  points. 
This  would  eliminate  the  need  for  multiple  local  uniques  to 
accomplish  the  same  task.   At  the  same  time,  this  could 
eliminate  some  keypunching  and  card-to-disk  processing 
required  today  for  payroll  processing,  if  such  an  approach 
were  tied  to  the  stock  point  SPLICE  interim  office 
automation  efforts. 61 

Secondly,  a  PE  HYPERchannel  interface  could  be  used  to 
provide  interface  among  NAVSCIPS  PEs  and  several  of  the 
required  foreign  interface  systems,  including  SPLICE.   This 
high  speed  data/computer  interface  could  be  used  in  lieu  of 
tape  file  transfers,  could  permit  SPLICE  terminals  to  access 
NAVSCIPS  processes  without  the  need  to  procure  additional 
terminals,  and  permit  the  transfer  of  NAVSCIPS  output 
products  directly  to  other  systems  without  the  need  for 
hardcopy  document  preparation.   Such  an  approach  would 
reduce  land  line  telecommunications  costs,  terminal 
procurement  costs,  and  manual  output  handling  costs. 

Thirdly,  the  NSC  Norfolk  EFT  process  could  be  adopted, 
documented,  and  used  as  a  Navy  standard  civilian  payroll 
interface  to  the  Federal  Reserve  System.   Selected  SPLICE 
sites  could  be  used  as  gateways  to  the  FRBs  for  all  of 


61ln  this  scenario,  the  authors  envision  local  stock 
point  division  administrative  personnel  inputting  T/A  data 
received  from  stock  point  employees  directly  on  SPLICE 
terminals  on  a  daily  basis.   Following  supervisor  on-line 
approval,  site  consolidation  and  forwarding  of  T/A  data  to 
the  NAVSCIPS  system  would  be  undertaken  on  whatever 
periodicity  is  required. 
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NAVSCIPS,  eliminating  need  for  each  NAVSCIPS  user  to  develop 
its  own  interface  or  use  manual  tape  handling  to  accomplish 
EFT  interface  requirements. 

The  next  area  to  be  addressed  is  the  NAVSCIPS  need  for 
migration  to  the  SPAR  environment.   NAVSCIPS  can  be  seen  as 
outside  the  sphere  of  SPAR  transition  and  modernization. 
Therefore,  SPAR  migration  would  be  a  non- issue.   However, 
the  source  data  input  requirements  to  NAVSCIPS  and  output 
product  integration  requirements  into  other  stock  point 
processes  are  real  issues.   SPLICE  can  accommodate  these 
requirements  during  the  SPAR  transition  phase.   SPAR  itself 
will  have  to  address  these  requirements  in  its  modernization 
phase . 

The  final  area  that  will  be  addressed  is  how  a  NAVSCIPS 
and  SPLICE  integration  effort  would  tactically  support  the 
NAVSCIPS  project  and  proposed  SPLICE  objectives,  thereby 
supporting  previously  presented  corporate  and  project  goals 
and  strategies.   The  NAVSCIPS-SPL I CE  interface  directly 
supports  and/or  is  supported  by  the  following  SPLICE  project 
objectives:  12,  15,  19,  21,  22,  27,  and  34. 

The  following  recommendations  should  be  evaluated  by  the 
NAVSCIPS  and  SPLICE  projects  to  assist  in  the  further 
attainment  of  Navy  cor porate/ proj ec t  goals  and  objectives: 

1.  Task  SPLICE  to  provide  a  standard  stock  point 
payroll  T/A  input  data  application  for  the  NAVSCIPS 
PE  systems . 

2.  Investigate  the  use  of  SPLICE  to  perform  the  EFT 
service  to  the  FRBs  as  a  standard  output  process 
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from  NAVSCIPS.   SPLICENet  could  also  be  used  to 
assist  in  distributing  EFT  inputs  to  SPLICE  sites 
which  would  perform  a  gateway  service  to  FRBs. 

3.  Investigate  the  use  of  the  SPLICE  HYPERchannel  as  an 
interface  to  NAVSCIPS  to  permit  on-line  input  passing, 
sharing  of  terminals,  and  output  report  distribution. 

4.  Investigate  the  use  of  SPLICE  as  an  alternate 
NAVSCIPS  hardware  suite,  for  sites  where  the  PE 
systems  are  anticipated  to  have  capacity  problems. 
This  recommendation  is  contingent  on  the  ability  of 
the  SEED  DBMS  products  being  implemented  on  SPLICE, 
in  a  manner  similar  to  the  way  TAPS  II  was 
transitioned  on  SPLICE. 

5.  In  the  event  that  recommendation  number  4  is  not 
feasible,  expedite  the  movement  of  NAVADS  and  IDA 
II(B)E  to  SPLICE  hardware  and  excess  the  larger  NAVSUP 
PE  systems  currently  used  by  these  applications  to 
NAVCOMPT  for  use  by  NAVSCIPS. 

This  concludes  the  discussion  of  NAVSCIPS  and  this 

section  on  financial  and  proc ur emen t/ contr ac ti ng  systems. 

SPLICE  shorebased  interoperability  is  the  next  area  that 

will  be  consider ed. 
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VII.   SHORE  BASED  INTEROPERABILITY 

A.  CHAPTER  OVERVIEW 

For  the  purposes  of  this  document,  interoperability  is 
defined  as  the  ability  of  multi-vendor  ADP  hardware  and 
software  systems  or  components  to  communicate  [Ref.  85]. 
Within  the  DOD,  interoperability  is  mandated  due  to  a 
diversity  of  vendor  products  used  by  DOD  which  must  be 
inter  faced . 62   This  chapter  will  address  how  SPLICE  assists 
NAVSUP  is  meeting  its  requirements  to  support 
interoperability  in  three  areas:  terminal  connections, 
intra- site  connections,  and  inter- site  connections. 

B.  TERMINAL  CONNECTIVITY 

For    the    first    decade    that    UADPS-SP    resided    on    Burroughs 
hosts,    terminal    (i.e.,    CRTs    and    printers)    connectivity    nad 
not    been    an    issue:    no    Burroughs    terminal    meant    no 
connectivity    to    the    Burroughs    systems.       This    was    primarily 
due    to    three    things:    Navy    use    of    the    Burroughs    Poll/Select 
protocol    and    data    formats;    ease    of    obtaining    Burroughs 
terminals    off    existing    Navy-Burroughs    contracts;    and    the 
inability    or    lack    of   desire    of    third    party    vendors    to 
produce    competitively    priced    Burroughs    compatible    terminals, 


62This    diversity    of    products    within    the    logistics 
community    is    due    primarily    to    ADP    open   market    competition 
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As  NAVSUP  began  its  move  into  a  CRT/remote  printer 
oriented  environment  at  the  stock  points,  particularly  on  PE 
minicomputers,  and  pressures  for  competitive  procurements 
mounted,  additional  sources  of  Burroughs  compatible  devices 
were  found  available  under  "brand  name  or  equal" 
procurements.   Contracts  were  given  to  alternate  sources 
resulting  in  a  proliferation  of  Burroughs  "work-alike"  CRTs 
(e.g.,  DATAMAX,  Delta  Datas,  ADM-31s,  etc.). 

As  time  progressed,  Burroughs  compatible  and  even  early 
Burroughs  terminal  devices  were  found  not  always  to  be  100% 
compatible  with  Navy  unique  software,  particularly  as 
Burroughs  made  changes  to  its  protocols.   Upgrades  (i.e., 
replacement  of  chips  or  new  firmware)  were  required  to 
existing  terminals,  often  free  if  Burroughs  had  provided 
them  and  not  so  when  obtained  from  third  parties. 
Additionally,  projects  began  to  request  greater 
functionality  (e.g.,  multiple  function  key  support,  large 
amounts  of  terminal  memory,  etc.)  than  the  older  Burroughs 
terminals  or  compatibles  supported.   The  need  to  accommodate 
other  terminal  devices  and  protocols  was  realized. 

These  events  influenced  NAVSUP  to  require  multi-vendor 
terminal  and  protocol  support  within  the  SPLICE  procurement. 
Due  to  the  large  inventory  of  Burroughs  and  compatible 
terminals  at  the  stock  points,  both  CRTs  and  remote 
printers,  SPLICE  would  not  only  require  full  support  for 
existing  Burroughs  devices,  but  would  also  require  support 
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for    a    series    of    compatibles    and    a    range    of    non-compatible 
devices,    most    noteworthy    being    those   manufactured    by    IBM    and 
IBM    compatible    devices. 63      a    summary    of    Government    Furnished 
Equipment    (GFE)     terminal    devices    which    were    listed     in    the 
SPLICE    contract    [Ref.    86]     is    provided    below: 

1.  Burroughs    and    Burroughs    compatible    CRTs    and    remotely 
addressable    printers; 

2.  IBM    3270    series    devices; 

3.  IBM    2780/3780    data    communications    protocols; 

4.  and    Asynchronous,    block/forms   mode    CRTs. 
Conspicuous    by    its    absence,    is    required    support    for    PCs. 

The    words    "terminal     support"    are    nebulous.    If    one    can 
physically    connect    a   device    to    the    system    is    that    support? 
Is    protocol     support    required?      What    if    only    some    terminal 
operating    modes    are    available?      Must    one    be    able    to    run    at 
least    some    or    all     system    supported    and    application    software? 
The    answers    to    these    questions    determines    the    level    of 
foreign    terminal     support    a    system    provides. 

To    ensure    there    were    no   misunderstandings    in    this 

critical    area,    three    requirements    were    specified    for 

"terminal    support"     in    the    SPLICE    procurement: 

1.      Government    furnished    data    communication    equipment 
identified    .     .     .    shall    be    interfaced.       Data 
communications    equipment    operation    shall    be    provided 
in    both    asynchronous    and    synchronous    communications 
modes    configured    on    both    point-to-point    and    multipoint 
lines    within    the    same    SPLICE    configuration.       The 


63with    IBM    or    IBM    compatible    terminals    representing 
approximately    70%    of    the    terminal    market,    this    step    appears 
j  ust  i  f i  ed  . 
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Contractor  provided  system  functions  available  to  a 
system  user  shall  be  available  from  any  data 
communications  equipment  which  has  facilities  for 
inputting  and  outputting  the  necessary  characters,  in 
any  of  the  communications  modes  and  line 
configurations.  [Ref.  87] 

2.  The  conversion  of  received  and  transmitted  data  shall 
be  provided  such  that  the  applications  software  shall 
be  independent  of  terminal  or  data  communications  line 
c  har ac ter  i  s t  ic  s  . 

3.  Data  Communications  Network  Software  shall  provide  for 
full  utilization  of  all  features  of  the  terminals 
[Ref.  88]. 

These  criteria  were  to  provide  for  use  of  all  native  mode 

terminal  capabilities,  in  all  operating  modes  and 

configurations,  requiring  all  system  software  and 

applications  to  fully  function  as  if  dealing  with  a  vendor 

terminal,  and  to  do  so  without  application  software  or 

configuration  changes.   Vendors  were  required  to  demonstrate 

portions  of  this  support  at  the  SPLICE  benchmarks. 

The  winning  vendor,  FDC,  was  able  to  demonstrate  full 
compliance  with  the  SPLICE  specifications  at  the  benchmarks, 
in  terms  of  the  "letter  of  the  law."   TANDEM  off-the-shelf 
hardware  and  software  provided  physical  connectivity, 
protocol  support,  as  well  as  higner  level  TANDEM  product 
interface  for  TANDEM  terminals  and  IBM  devices.   FDC 
provided  software  to  perform  data  format  mapping  and 
interface  to  higher  level  TANDEM  products  offerings  for 
"dumb"  asynchronous  block/form  mode  and  Burroughs  devices. 

FDC  was  also  concerned  enough  about  the  SPLICE  project 
and  the  many  initiatives  that  it  had  to  support  in  an 
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operational     environment    to    inform    the    government    at    that 
time    of   deficiencies    in    their    demonstrated    package    that 
would    require    extensive    revisions    to    meet    all     the    "spirit    of 
the    law"    requirements.       The    software    package    which    resulted 
from    this    re-write,    which    was    performed    at    no    cost    to    the 
government,    is    today    called    TMAP.64 

Specifically,    TMAP    supports    the    following    functions    for 
government    furnished    terminal     equipment: 

1.  supports  hardware  interface  and  communications  level 
protocol  for  GFE  terminals  in  v.arious  point-to-point 
and    multipoint    configurations; 

2.  provides    an    operating    mode    which    allows    block    mode 
applications    written    in    PATHWAY    to    treat    GFE    terminals 
as    if    they    were    TANDEM    6530    terminals;65 

3.  provides    an    operating    mode    which    allows    conversational 
or    teletype    access    to    the    Command    Interpreter,    FUP, 
EDIT,    etc.; 

4.  provides    an    operating    mode    which    allows    access    to    GFE 
printers    by    the    TANDEM    SPOOLER; 

5.  supports    virtual     function    key    support    for    GFE    CRTs; 

6.  and    performs    the    above    in    a   manner    which   makes    the 
terminal    type    transparent    to    the    application    program. 


6^In    that    TANDEM    and    IBM    terminals    are    supported 
completely    with    off-the-shelf    products    and    there    are    so    few 
of    these    currently    in    the    stock    point    inventory,    government 
interest    has    focused    most    closely    on    TMAP.       This    interest 
will     remain    high    as    other    terminals    from    the    remainder    of 
the    BUNCH    (i.e..    Burroughs,    Univac,    NCR,    CDC,    and    Honeywell 
must    be    interfaced    to    SPLICE. 

65Although    FDC    documentation    states    TANDEM    6530 
emulation    is    provided,    due    to    limitations    on    the    Burroughs 
CRTs,    TANDEM    6510    terminal     emulation    appears    closer    to    what 
is    being    provided. 
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There  was  sufficient  functionality  provided  here  to  permit 
implementation  of  immediate  application  packages  at  the 
stock  points  using  previously  procured  Burroughs  and 
compatible  devices,  as  augmented  by  SPLICE  procured  TANDEM 
6530  terminal s.  [Ref.  89] 

As  a  part  of  the  recently  accepted  FDC  SPLICENet 
proposal,  TMAP  functionality  will  be  transitioned  to  a  new 
FDC  product  for  TANDEM  called  the  Communications  Control 
Process  (CCP).   A  copy  of  CCP  will  reside  in  every  SPLICE 
system  at  a  site  under  the  control  of  a  site  Communications 
Environment  Manager  (CEM).   Within  CCP  are  vendor  unique 
terminal  handling  processes  called  Terminal  Initialization 
(TERM  INIT)  processes.   Four  TERM  INIT  processes  are 
currently  recognized  by  FDC  as  being  required:  IBM  3270,  IBM 
SNA,  Burroughs,  and  Honeywell.   [Ref.  90] 

Future  stock  point  processing  will  require  the 
incorporation  of  intelligent  workstations  or  PCs  onto  SPLICE 
(i.e.,  APADE).   IBM  PC  or  compatible  PC  support  can  be 
provided  under  SPLICE  in  four  ways: 

1.  The  government  can  procure  TANDEM  DYNAMITE 
workstations,  which  are  IBM  compatible  PCs. 

2.  PCs  may  be  interfaced  to  SPLICE  systems  as  TANDEM  6530 
terminals  via  third  party  terminal  emulation  packages, 
such  as  the  Microgate  6530  board/software.   Using  tne 
Microgate  6530  product,  in  addition  to  terminal 
emulation,  a  data  file  upload  and  download  software 
package,  with  format  translation,  is  available 
(FLASH) . 

3.  TANDEM  itself  supports  a  PC  interface  package  called 
PC  LINK,  usable  with  the  6100  communications 

sub  system  . 
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4.   TANDEM  has  announced  support  for  a  PC  LAN  interface, 
which  will  include  the  capability  for  PCs  on  a  Local 
Area  Network  (LAN)66  to  emulate  TANDEM  6530  terminals. 
Additional  support  includes  the  ability  of  PCs  on  the 
LAN  to  use  TANDEM  disk  storage  as  a  local  PC  drive 
(FILE  SERVER),  and  share  printers  (PRINT  SERVER). 
Many  command  interpreter  commands  to  the  TANDEM 
systems  may  be  entered  in  PC  formats  with  the  TANDEM 
system  making  required  conversions  to  TANDEM  formats. 

Although  the  authors  were  unable  to  locate  SPLICE 
contract  modifications  including  any  of  these  products, 
SPLICE  system  users  are  planning  to  obtain  many  of  these 
products  (i.e.,  NSC  Pearl  Harbor).   All  these  products  could 
be  provided  under  the  SPLICE  contract  substitution  clause. 

The  benefits  that  the  corporation  receives  from  SPLICE 
supporting  terminal  interoperability  are  fourfold: 

1.  SPLICE  can  introduce  new  applications  to  the  stock 
points,  including  new  functionality  in  the  interim  to 
SPAR,  while  protecting  the  existing  terminal  base. 
This  allows  for  phased  terminal  augmentations  or 
enhancements,  selective  terminal  replacement  as 
devices  reach  obsolescence,  and  greater  time  periods 
over  which  to  extend  replacement  costs. 

2.  SPLICE  allows  terminal  replacement  contracts  to  be 
more  functional  vice  vendor  product  or  interface 
specific.   This  enables  greater  competition  in  the 
procurement  process  and  should  result  in  lower 
terminal  replacement  costs. 

'3.   SPLICE  allows  a  single  terminal  to  access  multiple 
collocated  or  remote  hosts,  with  the  SPLICE  system 
handling  protocol  and  data  format  conversions  and 
permits  multiple  uses  of  a  terminal  on  the  same  host 
(i.e.,  word  and  data  processing).   This  reduces 
required  outlays  for  multiple  terminals  when  multiple 


^^Advance  product  announcements  indicate  support  for  any 
LAN  product  using  the  "NETBIOS"  standard  and  which  provides 
PC  hard  war e/ so f tware  to  connect  to  the  network.   Planned 
support  includes:  IBM  TOKEN  Ring,  STARLAN,  PC-Network, 
Ungermann-Bass  ETHERNET/OSI  and  ETHERNET/ TCP- I P . 
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incompatible    host    access    or    single    host    multifunction 
usage    is    required. 

4.       SPLICE'S    ability    to    use    multiple    vendor    terminals    to 
access    TANDEM    resident    applications    and    applications 
on    IBM    or    Burroughs    hosts    will     permit    a    phased 
terminal     transition    to    SPAR    without    having    to    disrupt 
the    communication    network    or    have    to    perform    a   massive 
replacement    of    older    terminal    devices    immediately. 

These    benefits    have    both    monetary    and    risk    reducing    aspects. 

There    appears    to    be    no    need    to   migrate    terminal 
interoperability    from    SPLICE    to    SPAR.       By    the    time    SPLICE    is 
replaced    by    SPAR    in    the    1990s,    all     stock    point    terminals 
will    have    been    replaced    with    SPAR    compatible   devices.      More 
importantly,    the    SPAR    single    vendor    support    concept    and 
reluctance    to    use    environmental     software    developed    uniquely 
for    the    Navy    would    preclude   migration    of    this    function 
simply    to    further    system    interoperability.       DON    must    be   made 
to    provide    required    terminal     interoperability    for    SPAR. 

SPLICE    terminal     interoperability    supports    the    following 
proposed    SPLICE    project    objectives:    1,    12,    13,    15,    16,    19, 
23,    29,    32,    33,    34,     35,     41,    44,    49,    and    50. 

The    authors    have    five    recommendations    to    improve    SPLICE 

support    for    terminal     interoperability: 

1.       Investigate    the    inclusion    of    Univac    CRTs    and    Data 

General    CAD/CAM    terminal    devices    under    TANDEM    physical 
and    protocol     support    and    FDC    CCP/TERM    INIT    support. 

a.       The    NARDAC    UllOO    systems    will    often    be    collocated 
with    UADPS-SP    Burroughs/SPLICE    systems.    Permitting 
Univac    terminals    (i.e.,    UTS    20,    UTS    30,    UTS    40, 
and    SperryLink    devices)    on    SPLICE    to    access    both 
UADPS-SP    applications    and    UllOO    applications 
(i.e.,    Naval    Air    Rework    Facility    applications)    may 
reduce    the    numbers    of    terminals    required    for    users 
to    perform    their    work,    reduce    local 
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telecommunication  line  costs,  and  increase  the 
range  of  potential  future  terminal  replacement 
V  end  or s . 

b.   The  EDMICS  interface  to  SPLICE  may  be  possible  by 
supporting  the  Data  General  CAD/CAM  terminals  on 
SPLICE  hosts  via  a  pass-through  mode  to  the  EDMICS 
hosts.   This  interface  would  be  similar  to  what  is 
done  today  in  EM3270  for  TANDEM  terminals  to  work 
with  IBM  hosts. 

2.  Expand  the  scope  of  CCP  support  to  include  additional 
printers,  including  laser  printers  for  APADE,  ABE, 
L06MARS,  and  NISTARS.   At  a  minimum,  those  devices 
used  today  in  NISTARS  should  be  addressed. 
Additionally  investigate  the  incorporation  of  large 
volume  laser  printer  support  (i.e.,  Xerox  9700)  either 
through  direct  connection  to  SPLICE  system,  through 
HYPERchannel  (type  A  or  B)  or  HYPERbus  connections,  or 
data  communications. 

3.  Review  the  functional  descriptions  of  the  TMAP 
replacement  products  in  light  of  the  SPLICE  contract 
terminal  requirements.   It  is  unclear  to  the  authors 
if  full  function  support  for  dumb  block/form  mode 
asynchronous  devices  is  available 
will  be  provided  under  CCP  (i.e., 
identified).   Either  the  contract 
require  change. 


und  er  TMAP  tod  ay  o  r 
no  TERM  IN  IT  proc  ess 
or  the  pro  po  sal  may 


4.  Ensure  that  dial- in  support  for  intelligent 
terminals/PCs  is  addressed  under  CCP  and  SAS, 
including  a  file  upload/download  facility. 67   Physical 
security  requirements  for  dial-in  support  should  also 
be  r e- ex  am  i n ed  . 

5.  FDC  should  be  tasked  with  including  local  area  PC  and 
terminal  network  support  under  SPLICENet.   PC  networks 
may  be  the  basis  of  interim  OA  at  the  stock  points  and 
NAVSUP  already  has  prototype  local  area  terminal 
networks  in  place,  which  may  not  be  compatible  with 
SPLICENet  (i.e.,  NSC  San  Diego  PLANet). 

This  concludes  the  discussion  on  terminal 

interoperability.   The  topic  of  SPLICE  support  for  intra- 

site  interoperability  will  next  be  discussed. 


^^This  area  must  be  addressed  in  support  of  shipboard 
users  not  having  direct  connect  SPLICE  access. 
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C.       INTRA-SITE    INTEROPERABILITY 

Intra-site    interoperability    within    SPLICE    is    planned    to 
be    accomplished     in    three    ways:    TANDEM  - to-TANDEM    local 
interconnection;    the    LCN    interconnection,    and    data 
communications    interconnection.       Each    of    these    methods    will 
be    addressed    to    show    how    it    accomplishes    intra-site 
interoperability.       Following    this,    the    benefits,    SPAR 
migration    need,    proposed    SPLICE    objectives,    and 
recommendations    for    improvements    in    this    area    will    be 
prov  id  ed  . 

I.      TANDEM -to-TANDEM    Interconnection 

With    the   definition    of    interoperability    provided    at 
the    beginning    of    this    chapter,    one   might    ask:    why    discuss 
TANDEM- to-TANDEM    interconnection?       Isn't    that    a    single 
vendor    situation?       Surprisingly,    the    answer    is    no. 

A    SPLICE    TANDEM    system    will    consist    of    from    2    to    16 
processors.      A    single    SPLICE    site    (i.e.,    NSC    Oakland)    may 
have    several    16    processor    SPLICE    systems.       Should    these    be 
interconnected?      If    so,    what    is    the    best    way    to    interconnect 
them:    via    TANDEM    products    or    via    the    LCN?      Additionally,    a 
stock    point   may    have    a    Sperry    Univac    provided    TANDEM    Non- 
stop   II    system    for    NISTARS    which    need    not    be    configured    to 
account    for    or    operate    with    SPLICE.       The    issue    of    connecting 
multi-vendor    TANDEM    configurations   must    also    be    addressed. 

The    authors    contend    that    all     SPLICE    systems    at    a 
site    should    be    interconnected    via    TANDEM    products.       This 
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provides    for    the    greatest    possible    spread    of    processes    and 
files    across    available    assets,    should    facilitate   multiple 
application    tuning    efforts,    and    provides    additional 
contingency    resources    without    reconfiguration.       However, 
there    are    also    performance    factors    in    this    contention. 

The    TANDEM    host    interface    product,    EXPAND/FOX,     is 
preferred    over    the    non-TANDEM    LCN    due    to    effective    data 
transfer    rate    considerations    and    processing    software 
considerations.       An    effective   data    transfer    rate    of    1 
megabyte/ second    (per    cable    with    up    to    four    cables)    [Ref.    91] 
can    be    attained    through    TANDEM    off-the-shelf    products    while 
only    a    300    k i 1 obytes/ second    burst    rate    [Ref.    92]     is 
achievable    through    the    LCN    (TANDEM    HYPER    Link)     interface 
controller.       Additionally,    the    TANDEM    EXPAND    software    has 
been    specifically    incorporated    into    and    optimized    for    the 
operating    system,    while    the    LCN    software,    NETEX    or    TABU,    is 
essentially    an    application    add-on. 

The    authors    have    already    taken    the    stand    in 
discussing    the    NI STARS-SPLI CE    interface    that    the    two 
configurations    at    a    site    should    be    interconnected.       Besides 
the    application    integration    advantages    from    doing    this, 
backup    and    contingency    concerns    drive    this    recommendation. 
The    question    of    how    this    should    be    accomplished,    physically 
and    with    what    software,    remains    to    be    addressed. 

The    recommended    means    to    provide    TANDEM- to-TANDEM 
system    interface    intra-site,    regardless    of    the    physical 
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media,    is    through    a    bundled    software    extension    to    the    TANDEM 
operating    system    called    EXPAND.       This    operating    system 
extension    enables    systems    which    are    not    connected    via    the 
DYNABUS^S    to    operate    as    if    they    were    a    single    system    without 
application    program    changes.       The   methods    used    to    accomplish 
this,    along    with    product    features    and    components,    are 
described     in    [Ref.    93].       For    the    purposes    of    this    document, 
it    is    only    important    to    note    that    EXPAND    permits: 

1.  a    process    on    one    node    to    access    and    use    resources, 
including    files,    on    other    nodes; 

2.  users    on    any    node    to    access    processes    or   data    on    any 
other    node,    subject    to    security    constraints; 

3.  a    process    on    one    node    to    send    or    receive    transactions 
to    and    from    a    process    on    another    node; 

4.  and    guaranteed    end-to-end    data    integrity    and 
notification    to    the    sending    process    of   delivery 
fa  i  1  ur e. 69 

All    of    these    capabilities    are    of    use    in    intra-site,    NISTARS 
TANDEM-to-SPLICE    TANDEM    interconnection. 

Physically,    the    EXPAND    software    can    use    any    of    four 
media    to    complete    system    interconnection:    direct    connect, 
fiber    optic    cables,    X.25    lines,    or    satellite    transmissions. 
Only    the    former    two    are    of    interest    in    the    area    of    SPLICE 
intra-site    connectivity    due    to    the    cost    and    distance 
involved.       The    authors    purpose    that    SPLICE    TANDEM-to- 


^^The    DYNABUS    is    a    high    speed     i n ter- proc e sso r 
communications    bus    for    single    TANDEM    systems    (i.e.,    up    to    16 
proc  essor s) 

6^ "Guaranteed"    delivery    is    not    provided,    although    this 
too    can    be    provided    via    an    interface    to    TRANSFER. 
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NISTARS  TANDEM  interconnection  be  accomplish  preferably  via 
the  TANDEM  EXPAND/FOX  fiber  optic  subsystem  (FOX),  where  the 
distance  between  systems  is  less  than  1  kilometer  and 
sufficient  slots  can  be  found  to  support  the  FOX  controllers 
on  all  systems.   The  lesser  preferred  alternative  would  be 
interconnection  through  EXPAND/Direct  Connect  links,  using 
the  highest  speed,  best  grade  data  lines  available  at  a  site 
(up  to  55  kilobytes/second). 

2.   The  LCN  Intra-site  Interconnection 

SPLICE    systems    will    be    collocated    with    non-TANDEM 
systems.       These    non-TANDEM    systems    include    IBM,    Burroughs, 
Univac,    and    PE    systems.       The    need    to    interface    these    systems 
for    transaction    and    bulk    file    passing    appears    to    exist. 

Two    basic    concepts    of    SPLICE    have    always    been    that 
all    computers    collocated    with    SPLICE    would    be    interconnected 
to    each    other    and    SPLICE    via    the    LCN,    and    that    off-the-shelf 
software    would    be    used    to    support    the    LCN.       In    accordance 
with    the    SPLICE    contract,    this    would    mandate    use    of    Network 
Systems    Corporation    HYPERc hannel s    and    Network    Executive 
(NETEX)     software.       To    date,    neither    of    these    concepts    has 
been    exploited    within    SPLICE,    although    the    SPLICENet 
proposal     re-affirms    the    latter.       Current    SPLICE    LCN 
initiatives    support    the    intra-site    interconnection    of    only 
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TANDEM  and  Burroughs  systems  and  this  is  done  through  Navy 
developed  software. 70 

The  reasons  for  these  deviations  from  original 
SPLICE  plans  are  varied.   First,  consider  non-ADP  issues: 

1.  NAVDAC  has  never  approved  a  SPLICE-UllOO  interface  via 
the  LCN.   This  is  the  case  in  spite  of:  the  UADPS-SP 
Burroughs  to  NIMMS  (UllOO)  interface  requirement, 71  a 
similar  NARDAC  New  Orleans  HYPERchannel  project 
exists,  and  general  NARDAC  NARF  support  were  the 
driving  forces  behind  the  original  requirement. 72 

2.  FMSO  application  development  personnel  were  not 
brought  into  the  planning  process.   NAVSUP  application 
support  (e.g.,  FMSO  developed  PE  IDA)  was  the 
rationale  for  a  SPLICE-PE  interface,  particularly  in 
the  area  of  transaction  passing  to  the  Burroughs  and 
bulk  file  transfers  to  eliminate  tape  handling  at 
stock  points.   Once  the  SPLICE  contract  was  in  place 
making  development  of  these  interfaces  possible,  it 
was  FMSO  application  personnel  that  claimed  there 
existed  no  need  for  such  an  interface  since  existing 
tape  passing  was  working  and  application  changes  and 
costs  to  implement  the  changes  outweighed  benefits. 

3.  Inability  of  disparate  projects  to  acknowledge  and 
accept  areas  of  overlap.   In  many  of  the  stock  points 
the  SPLICE,  IDAFIPS,  and  NAVSCIPS  systems  will  be 
within  LCN  connection  range.   No  plans  exist  to 
connect  these.  SPLICE  sites  at  the  ICPs  will  be 


70with  the  exception  of  the  SPLICE  Computer  Operations 
Manual,  all  FMSO  and  FDC  SPLICENet  documentation  held  by  the 
authors  discusses  the  NETEX  software  as  being  used  to 
support  SPLICE  HYPERchannel  operations.   The  best 
information  obtainable  by  the  authors  is  that  TABU,  the  Navy 
developed  HYPERchannel  software,  is  being  used  and  will 
continue  to  be  used  in  lieu  of  NETEX  on  the  Burroughs  systems 

7lThis  interface  is  accomplished  today  by  a  PE 
minicomputer  which  is  used  to  do  little  more  than  pass 
transactions  between  Burroughs  and  Univac  hosts. 


72no  response  was  received  to  letters 
requesting  clarification  on  this  issue. 


written  to  NAVDAC 
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connected  to  IBM  3080/3090 
communications  (i.e.,  SNA) 


series 
73 


systems    via    data 


Second,    consider    the    following    ADP    related    issues: 

SPLICE    LCN    software    requirements    within    the    contract 
called    for    interconnection    software    that   meets    ISO    OSI 
standards    for    interconnection    [Ref.    94].       This    is    so 
despite    the    fact    that    two    SPLICE    sponsored    studies    at 
NPS    Monterey    indicated    this    would    be    unnecessary 
overhead    and    it    would    adversely    affect    host/LCN 
performance.    [Refs.    95    and    96]. 74 

The    preliminary    deliveries    of    Burroughs    NETEX 
confirmed    the    performance    problem    cited    in    the    studies 
since    the    software    could    only    be    run    on    larger    Navy 
Burroughs    systems    and    then    only    at    the    sacrifice    of 
some    application    processing.      Therefore,    the    Navy 
developed    their    own    HYPERchannel     software    for    the    two 
immediately    required    systems    (i.e.,    TABU).       The 
authors    anticipate    that    similar    capacity    and 
performance    problems    will    exist    on    smaller    PE    systems. 

Off-the-shelf    NETEX    software   does    not    provide    all    the 
functionality    required    (i.e.,    layers    up    to    and 
including    presentation)     in    the    SPLICE    contract.    FDC 
was    required    to    supplement    it    with    additional 
software.       This    required    development    time    after 
delivery    of    acceptable    lower    level     software    products 
and    would    not   meet    Navy    implementation    schedules. 
This    area    too    is    under    re-design    in    SPLICENet.75 


73The    rationale    for    this    is    unclear    to    the    authors. 
Explanations    from    lower    level    FMSO    personnel     include    that 
HYPERchannel     is    not    recognized    as    an    "IBM    strategic    product" 
and    the    interface    would    require    the    use    of    "Navy    unique 
software"    to    implement. 

7^X0    obtain    off-the-shelf    software    in    the    contract    it 
was    necessary    to    specify    some    standard.    The    ISO    OSI    standard 
was    the    only    one    seen    as    available/applicable    to    the    SPLICE 
system,     including    the    LCN. 

75The    SPLICENet    proposal     indicates    that    a    SNA    like 
hierarchy    would    be    established    for    HY PERc hannel / NETEX    usage. 
A    CCP    would    control    LCN    usage    through    Communications 
Interface    Packages    (CIPs)    on    each    background    host    processor. 
These    CIPs    interface    to    HYPERchannel    via    NETEX.      When    a    CIP- 
to-CIP    session    is    required,    the    CCP    accomplishes    it. 
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The    use    of    the    Navy    developed    HYPERchannel     software 
in    SPLICE    for    TANDEM    and    Burroughs    has    thoroughly    proven    the 
concept    of    high    speed     inter-computer    communications    for 
interoperability    within    the    stock    point    environment. 
Previously,    the    REP    FILES    and    TRANSRECON    Offload 
applications    were    discussed    supporting    this.       The    other 
major    proof    of    this    is    found     in    the    Navy    developed    Burroughs 
Pre-Processing    module    on    SPLICE. 

The    Burroughs    Pre-Processing    module    permits:    1. 
users    on    SPLICE    terminals    or    processes    to    obtain    access    to    a 
pass    through    application;    2.    creation/storage/ presentation 
of    TANDEM    screen    images    of    Burroughs    frames    for    optional 
use;    and    3.    passing    of    SPLICE    generated    standard    Burroughs 
transactions    to    on-line    Burroughs    programs    or    queues.       Once 
in    the    pass    through    application,    inputs    are    passed    out    of 
SPLICE,    through    the    HYPERchannel,    and    to    the    Navy    Burrougns 
data    communications    manager    (SDCH),    while    Burroughs    outputs 
are    passed    back    via    a    similar    path    to    input    CRTs,    remote 
printers    located    on    SPLICE,    or   may    be    inputs    to    holding 
files    or    other    processes.       When    the    Burroughs    systems    are 
down.    Burroughs    destined     inputs    are    stored    for    future 
passing    to    them.       Unexpected    Burroughs    generated 
transactions    may    also    be    passed    to    SPLICE    via    this    module 
and    forward    to    SPLICE    proc e s se s/ f i 1 es .    [Refs.    97    and    98] 

The    authors    found    no    documentation    concerning    a    Navy 
unique    implementation    of    a    bulk    file    transfer   module    using 
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the    HYPERc hannel s    and    TABU.       Although    such    development    is 
well    within    FMSO's    capability,    it    appears    that    future    NETEX 
releases   may    be    used    to    fill    this    role,    eliminating    the    need 
for    further    Navy    unique    development. 

3.   Data  Communications  Interconnection 

In    light    of    the    failure    of    the    LCN    concept    being 
exploited,    some    stock    point    intra-site    computer    connectivity 
will     still    require   data    communications    interfaces.       In    these 
situations,    SPLICE    can    perform    the    required    interface 
function    for    terminal    users    and    processes. 

In    chapters    IV    through    VII,    some    of    the    NAVSUP 
applications    requiring    intra-site    data    communications 
interface    are   discussed.       Specifically,    these    are    FMSO    IDA, 
NAVADS,    NISTARS,    and    On-Line    AUTODIN    (OLA). 

FMSO    IDA,    NAVADS,    and    OLA    are    planned    to    transition 
to    SPLICE,    therefore,    no    effort    appears    necessary    to 
interface    their    current    data    communications    requirements    to 
SPLICE. 76      These    transitions    to    SPLICE    also    obviate    the    need 
for    the    PE    LCN    interface    entirely    within    NAVSUP.       NAVSCIPS 
and    NIMMS    still    present    unresolved    PE    interface    problems. 

Recommendations    were    previously    made    to    eliminate 
the    NISTARS-to-Burroughs    data    communications    interface    and 
replace    it    with    direct    TANDEM-to-TANDEM    connections.       The 
FDC    SPLICENet    proposal     specifically    addresses    the    EXPAND/FOX 


76if    it    were    necessary    to    do    this,    the    current    NAVADS- 
to-NISTARS   data    communications    interface    could    easily    be 
incorporated     into    SPLICE. 

175 


interface    required     in    this    case    and    alludes    to    the 
alternative    EXPAND/Direct    Connect    interface    as    an    exception 
for    MAPS    RJE    site    processing.       To    accomplish    the    NISTARS- 
SPLICE    interface,    this    exception    may    be    the    rule   due    to 
distance    between    systems. 

Outside    of    3urroughs-to-Burroughs    terminal 
concentrator    and    RJE    intra-site    data    communications,    which 
can    be    eliminated    by    moving    terminals    and    processing 
directly    over    to    SPLICE,    there    is    only    one    other    firm    intra- 
site    data    communications    interface    required:    IBM-to- 
SPL  I  CE/ B ur ro ug h s .       This    interface    is    required     in    support    of 
the    TRIDENT    LDS,    but    will     also    apply    to    the    ICP 
Resolicitation    system    interface.       These    systems    prefer 
standard    System    Network    Architecture    (SNA)    SPLICE    interface 
over    HYPERchannel     interface. 

The    TRIDENT    LDS    system    has    recently    been 
transitioned    from    PE    equipment    to    IBM    4300    series 
hardware/software    obtained    off    the    ICP    Resolicitation 
contract.       Part    of    this    transition    required    the    replacement 
of    the    previous    TRIDENT    LDS-to-UADPS    terminal     and    process 
data    communications    hardware    and    software    interfaces,    which 
were    called    collectively    the    NCP.       NCP    resided    on    PE 
hardware    and    connected    local    PE    systems    to    remote    Burroughs 
systems    for    transaction    passing,    while    simultaneously 
permitting    terminals    on    it    to    access    either    system.       When 
the    Burroughs    host    which    supported    a    portion    of    TRIDENT    LDS 
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was  moved  to  the  TRIDENT  Refit  Facility  (TRF),  Bangor,  the 
need  to  interface  a  Burroughs  host  collocated  with  an  IBM 
host  through  data  communications  was  recognized. 

FDC  was  able  to  accomplish  this  through  a 
combination  of  TANDEM,  IBM,  and  third  party  software.   Three 
situations  had  to  be  accommodated: 

1.  a  user  requiring  access  to  data/processes  on  either 
the  IBM  or  Burroughs  system  on  a  regular  basis; 

2.  a  user  on  the  IBM  system  requiring  infrequent  access 
to  the  Burroughs  system; 

3.  and  an  application  on  IBM  sending  transactions  to  an 
application  on  Burroughs,  and  vice  versa. 

Situation  number  one  was  accommodated  by  placing  the 
bi-directional  terminals  on  SPLICE.   Terminal  access  to 
Burroughs  was  provided  via  the  SPLICE  Burroughs  Pre- 
processor and  related  hard  war e/ so f twar e  .   IBM  access77  was 
provided  by  installing  on  the  TANDEMs:  EM3270  to  make  TANDEM 
terminals  able  to  emulate  IBM  3270  terminals;78  direct 
support  of  IBM  terminals  on  SPLICE;  SNAX  which  provides  the 
SOLC  link  level  protocol  required  to  interface  to  the  IBM 


77Assumes  an  IBM  host  running  MVS  or  MVS/XA,  ACF/VTAM, 
and  CICS  or  other  LU  6.2  software. 

^Sjhe  authors  are  making  the  assumption  that  Burroughs 
terminals  emulating  TANDEM  5530s  via  the  FDC  TERM 
IN  IT/ Burroug hs  software  (old  TMAP)  can  be  interfaced  to 
EM3270  to  enable  IBM  system  usage.   If  this  is  not  so,  much 
of  the  existing  Burroughs  terminal  base  is  in  jeopardy  and 
one  of  the  basic  tenants  of  the  SPLICE  contract  (i.e.,  full 
support  for  Burroughs  terminals)  has  been  discarded.   This 
capability  is  considered  critical. 
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host  [Ref.  99], 79  and  3.  SNAX  Hign  Level  Support  (SNAX/HLS), 
which  provides  Transmission  Control  services  required  by 
SNA.   To  begin  use  of  the  IBM  system  from  a  SPLICE  terminal, 
the  user  must  self-initiate  the  session  with  an  initiation 
and  logon  request,  indicating  the  line  leading  to  the  IBM 
host  and  the  name  of  the  IBM  host  application  that  is  to 
process  the  logon  request.   SNAX  then  initiates  the  session. 
From  there,  normal  IBM  processing  continues. 

The  second  situation  is  more  complicated.   In 
addition  to  the  products  already  assumed  on  the  IBM  and 
TANDEM,  several  other  products  are  required.   A  product 
called  Host  Command  Facility  (HCF)  is  required  on  the  IBM 
system.   User  logon  to  this  product  permits  terminals  on  the 
IBM  system  to  interface,  through  VTAM/ SNAX / SNAX  HLS,  to  a 
FDC  provided  TANDEM  process  called  DHCFNET.   To  do  this,  the 
IBM  user  must  execute  the  HCF  software  and  then  input  an 
ACQUIRE  command,  followed  by  the  SNA  logical  unit  (LU  NAME) 
assigned  to  the  terminal.   DHCFNET  performs  mapping 
functions  and  interfaces  to  the  FDC  SAS  system.   After  a 
short  period  of  time  following  presentation  of  a  FDC  welcome 
message,  the  user  is  "pushed"  the  SAS  logon  screen,  from 


79The  TANDEM  SNAX  product  includes  a  PASSTHROUGH 
function.   This  function  permits  an  IBM  host  application 
program  to  communicate  with  TANDEM  connected  SNA  compatible 
devices  as  though  they  were  connected  to  a  host  cluster 
controller.   The  function  is  enabled  by  configuration  and 
startup  procedures,  vice  software  enabled. 
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which  Burroughs  Pre-Processor  may  be  selected  for  further 
processing  on  the  Burroughs  host.  [Refs.  100  and  101] 

The  third  situation  is  accomplished  by  adding  yet  an 
additional  product  to  the  TANDEM  for  interface  to  provide  LU 
6.2  interface  to  the  IBM  side:  SIXTWO  [Ref.  102].   Although 
no  specific  references  were  found  describing  the  actual 
processing  scenario  being  used  at  TRF,  the  authors  can 
provide  a  summary  of  how  processing  can  be  accomplished. 

The  SIXTWO  product  on  TANDEM  allows  SPLICE 
applications  to  pass  transactions  to  and  receive 
transactions  from  LU  6.2  programs  on  the  IBM,  by  providing 
the  required  port  to  the  SNA  network.   Normal  SNA  services, 
such  as  Transmission  Control,  Data  Flow  Control,  Logical 
Unit  Network  Services,  Resource  Management  Services, 
Presentation  Services,  and  Control  Point  services  are 
provided  by  SIXTWO  which  interfaces  to  SNAX  using  SNALU. 
Transaction  programs  on  both  IBM  (i.e.,  CICS/TAPS 
applications  from  TRIDENT  LDS)  or  TANDEM  (i.e.,  PATHWAY 
applications  accepting  requests  for/from  Burroughs  Pre- 
processor) can  both  make  calls  on  SIXTWO.   SIXTWO  initiates 
all  required  session  services  on  behalf  of  the  two  parties 
wishing  to  pass  data,  and  when  both  processes  are  on-line, 
permits  a  pass  through  of  the  initiator's  data  to  the 
reception  point.   After  acknowledgement  of  receipt,  the 
session  may  be  terminated. 
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The    basic    principals    of    this    SNA    interface    between 
SPLICE    and    IBM    have    been    incorporated    into    the    new    FDC 
SPLICENet    proposal.       This    interface    is    described    as    a 
"gateway    interface",    and    pre-supposes    NETEX    instead    of    TA3U 
for    the    Burroughs    connection.       A    similar    interface   may    be 
implemented    at    both    Navy    ICPs    under    Re  sol ic i ta t ion    for    stock 
point    access    to    ICP    programs    and    files    (i.e.,    ICPNet). 

Having    discussed    the    three    ways    in    which    intra-site 
interoperability    will    be    provided    for    under    SPLICE,    what 
benefits    which    can    accrue    from    their    implementation?       In 
terms    of    TANDEM- to-TANDEM    intra-site    interface,    application 
integration,    resource    sharing,    and    b ac k up/ r ed und ancy    are    all 
potential    benefits.      The    benefits    the    LCN    interface    provides 
include:    a   method    to    interface    new    applications    to    the 
Burroughs    or    a   means    to    permit    additional     terminal     access    to 
the    Burroughs    without    adding    Burroughs    workload;    a   means    to 
share    resources    among    collocated    systems;    an    alternate   means 
to    access    Burroughs   master    file    data    (i.e.,    REP    FILES);    a 
means    to    extend    the    life    of    the    Burroughs    while    awaiting 
SPAR;    and    a    vendor    independent    data    communications    subsystem 
for    SPAR.       Finally,    the    benefits    that    intra-site    data 
communications    provide    are:    SNA    compatibility    and    access; 
ability    to    share    terminals    among    different    systems;    and    the 
ability    to    pass    and    share    data    among    collocated    multiple 
vendor    systems.       This    last    benefit    is    particularly    important 
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in    that    access    to    ICP    data    for    inquiry    can    be    accomplished 
through    this    over    SPLICENet. 

Intra-site    interoperability    will     be    important    to    the 
stock    points    during    and    after    full     SPAR    implementation, 
regardless    of    their    long    term    single    vendor    concept.       There 
will    be    BBN,    PE,    Univac,    large    scale    Burroughs,    and    possibly 
even    Honeywell     systems    collocated    with    the    new    SPAR    hardware 
at    some    stock    points.      With    SPLICE    present,    there    should    be 
no    need    to    migrate    intra-site    interoperability:    SPLICE    will 
provide    for    it.       However    in    long    term,    SPAR    itself    will    need 
to    accommodate    this    in    the    SPLICE    replacement    upgrade. 

Intra-site  interoperability  supports  or  is  supported 
by  the  following  proposed  SPLICE  objectives:  6,  8,  12,  19, 
21,    23,    26,    29,    32,    33,    41,    44,    47,    and    48. 

The  authors  recommend  the  following  actions  be  taken 
to    improve    support    in    this    area: 

1.  Perform    a    site    survey    of    planned    NISTARS    sites    to 
determine    if: 

a.  NISTARS    systems    are    close    enough    to    SPLICE    systems 
to    use    FOX; 

b.  FOX    cables    can    be    physically    run    from    the    SPLICE 
systems    to    the    NISTARS    systems; 

c.  sufficient    ports    exist    on    the    NISTARS    systems    to 
support    FOX    controllers. 

Incorporate    the    results    into    SPLICENet    plans 
indicating    required    support    by    site. 

2.  If    TANDEM- to-TANDEM    intra-site    connections   must    use 
EXPAND/Direct    Connect,    revise    the    SPLICENet    proposal 
to    elaborate    on    the    Navy    interface    requirements    to    use 
CEM. 
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Confirm  the  requirements  for  LCN  connectivity. 

a.  If  NAVDAC  does  not  permit  Univac  access,  delete 
the  Univac  LCN  requirement  from  the  contract  and 
the  SPLICENet  proposal . 

b.  If  FMSO  and  NAVCOMPTSSA  do  not  require  PE  access 
to  the  LCN,  delete  the  PE  LCN  requirement  from  the 
contract  and  the  SPLICENet  proposal. 80 

c.  If  ICP  and  TRIDENT  remain  disposed  to  not  using 
HYPERc hannel ,  reevaluate  the  purpose  of  the  ISM 
LCN  interface.   If  it  is  there  to  support  other 
older  stock  point  IBM  systems,  validate  the  system 
and  communications  software  now  being  used:  a  MVS 
based  plan  may  be  inappropriate.   Revise  or  delete 
the  requirement  in  the  contract  and  the  SPLICENet 
proposal  accordingly. 

d.  Honeywell  DPS6  systems  will  be  installed  at  some 
NARDAC  sites.   Determine  if  a  LCN  interface  is 
appropriate  and  desired  for  use  there. 

e.  The  IDAFIPS  Burroughs  6900  systems  may  be 
collocated  with  other  stock  point  systems  (i.e., 
NARDAC  Jacksonville).   Determine  if  a  LCN 
interface  is  appropriate  and  desired  for  use 
there . 

Reevaluate  the  SPLICE  contract  requirement  for  use  of 
the  ISO  OSI  standard  in  LCN  software.   Permit  FDC  the 
option  to  substitute  other  LCN  software  with  fewer 
layers  and  designed  to  optimize  LAN  performance  over 
redundant  and  unnecessary  wide  area  network  error 
detection  and  correction  integrity  features. 


Have  FMSO  develop,  document,  and  deploy  TABU 
bulk  file  transfer  software. 81 


based 


Based  on  operational  data  received  to  date, 
investigate  the  optimum  configuration  for  HYPERchannel 
traffic  over  adapters,  particularly  on  the  TANDEM 
side,  as  well  as  trunk  line  dedication.   In  a  similar 


SOjhere  is  probably  insufficient  capacity  on  their 
NAVSCIPS  PE  3210  systems  to  support  both  NETEX  and  PE  CIP 
anyway.   This  also  should  be  validated. 

8lThe  authors  understand  from  discussions  with  NAVSUP 
personnel  that  this  software  may  already  exist,  although 
documentation  was  not  located  on  it. 
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light,    optimize    Burroughs    Pre-Processor/TABU    software 
to    improve    user    terminal    response    times. 

7.       Investigate    user    dissatisfaction    over    current    SNA 
terminal    connectivity    requirements.       It    should    be 
possible    for    interface    software    to    provide    required    LU 
data    and    menu    selection    of   desired    application.82 

This    concludes    the    discussion    on    intra-site 

interoperability.       Inter-site    interoperability    will    be 

add  ressed    next. 


D.       INTER-SITE    INTEROPERABILITY 

Although    someday,    inter-site    interoperability    may    be    the 
exclusive   domain    of    the    DDN,    that   day    does    not    appear    to    be 
in    the    immediate    future.       Five    areas    of    inter-site 
interoperability   must    be    addressed    by    SPLICE:    shore    based 
system    access,    MAPS    RJE    activity    access,    DLANet    access,    DDN 
access,    and    DAAS/AUTODIN    I    access.       Following    a    discussion 
of    how    SPLICE    will    provide    interoperability    in    each    of    these 
cases,    benefits    to    the    corporation,    SPAR   migration    need, 
proposed    SPLICE    objectives    supporting    and    supported    by    each, 
and    recommendations    for    improvements    will    be   made. 

1.      Shore    Based    System    Access 

Certain    shore    based    activities    such    as    Ships 
Intermediate    Maintenance    Activities    (SIMAs),    non-TRIDENT 
Submarine    Base    Repair    Facilities,    non-deployed    air 
squadrons,    and    Naval    Shipyards,    etc.,    currently    do    and    will 
continue    to    require    interface    to    the    Navy    Supply    System. 


82This    recommendation    is    based    on    discussions    with    FMSO 
TRIDENT    project    office    personnel. 
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Many  of  these  activities  will  be  using  SNAP  I  compatible 
Honeywell  equipment:  EDMICS,  using  Data  General  equipment, 
is  a  notable  exception.   Some  of  these  activities  are  within 
a  few  miles  of  supporting  Supply  Centers  making  DON 
interface  inappropriate.   This  leaves  local  data 
communications  as  the  primary  access  media  for 
interoperability  and  horizontal/vertical  integration. 
Neither  the  SPLICE  contract  nor  the  SPLICENet 
proposal  make  reference  to  these  interfaces.   Although  there 
is  insufficient  time  in  this  study  to  investigate  and 
propose  individual  interfaces  for  these  systems,  the 
requirement  to  do  so  does  appear  to  exit,  and  SPLICE  must  be 
the  vehicle  to  meet  the  r equ i r emen t . 83 
2.   MAPS  RJE  Activity  Access 

MAPS  is  a  Navy  unique  environmental  package,  usable 
by  both  host  and  satellite  personnel,  which  enables  better 
management  of  batch  processing  on  Burroughs  hosts.   MAPS 
provides  for:  [Ref.  103] 

1.  automatic  execution  of  a  series  or  stream  of  programs 
which  have  been  pr e-ca tal og ed .   Both  high  priority  and 
pre-scheduled  normal  priority  jobs  may  be  executed. 

2.  automatic  file  selection  and  verification  for  up  to 
nine  collocated  activity  codes  (i.e.,  different  users 
and  files)  operating  on  the  same  Burroughs  host. 

3.  remote  input  of  job  stream  data  files  (inputs)  from 
satellite  sites  through  data  communications.   Remote 
inputs  are  specially  validated  and  formatted  to 
prevent  erroneously  formatted  job  inputs  from  ever 


83see  Chapter  8  for  several  possible  methods  to 
interface  Honeywell  DPS  6  series  hardware. 
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reaching    the    Burroughs    host    and    to    facilitate    transfer 
of   job    inputs    over   data    communications    lines    (i.e., 
com  pac  tion    of   data). 

4.  host    output    management    including    file    collection    to 
prevent    loss,    tape    library    functions,    and    managing    of 
paper    (i.e.,    part    forms    required)     and    card    outputs. 

5.  remote    output    management    including    the    compaction    of 
outputs    satellite    bound    to    facilitate   data 
transmission,    the    decompaction    of   outputs    once    at    the 
satellite    for    local     pr i n t i ng/ punc h i ng ,    bulk    file 
transfers    to    satellite    disk    or    tape,    and    special 
formats    and    support    for    immediate    print    and    punch 
requirements. 

6.  inquires    to    the    host    system    for    job    or    output    status. 

7.  restart/ recov ery    support. 

8.  terminal    concentration    support    to    reduce    satellite 
telecommunication    line    costs. 

Phase    II    of    SPLICE    will    address    those    portions    of    MAPS    and 

associated    Burroughs    software    which    support    satellite 

operations    in    terms    of    both    MAPS    RJE    satellite    activity 

system    replacement    and    data    communications    access. 84 

In    the    original    SPLICE    plans,    all     existing    MAPS    RJE 

sites    were   designated    to    receive    SPLICE    hardware.       This 

remote    SPLICE    hardware    would    be    interfaced    through    local 

data    communications    lines    and    off-the-shelf    SPLICE    software 

to    host    SPLICE    complexes    and    then    to    the    Burroughs    itself 

through    the    LCN.       Much    of    the    unique    satellite    software    used 

today    would    be    unnecessary,    as    normal    SPLICE    complex 

software    (e.g.,    Burroughs    Pass-Thru,    bulk    file    transfer, 


84a    satellite    activity    can    be    as    close    as    one   mile    away 
from    its    host    site    (i.e,    SUBASE    Pearl     Harbor)     or    several 
hundred    miles    (i.e.,    NTC    Great    Lakes).       This    potentially 
means    that    DDN    may    be    used    for    MAPS    RJE    satellite    support. 
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etc.)  could  be  used  to  forward  uncompacted  inputs  to  and 

receive  uncompacted  outputs  from  the  Burroughs  via  the 

SPLICE  complex.   Navy  development  could  thus  concentrate  on 

merely  supplementing  the  already  existing  SPLICE  complex 

software  with  special  satellite  software  to  validate  inputs 

to  catalogued  job  streams  and  remote  site  output  management. 

Two  problems  have  emerged  which  appear  to  be 

modifying  this  plan.   The  replacement  SPLICE  hardware  for 

all  MAPS  RJE  sites  was  not  necessarily  budgeted  for  by 

NAVSUP.   Additionally,  some  of  the  Burroughs  satellite 

hardware  currently  in  use  is  of  rather  recent  vintage  and, 

therefore,  does  not  require  immediate  replacement.   Both  of 

these  facts  seem  to  have  prompted  the  following  sentence 

which  is  taken  from  the  SPLICE  SDP  III  Executive  Summary: 

Remote  Job  Entry  (RJE)  sites  which  use  the  Burroughs 
Poll/Select  protocol  will  remain  on  dedicated  circuits  to 
the  host  Stock  Points  or  to  the  nearest  SPLICE  site.  [Ref. 
104] 

From  this  statement,  SPLICE  Phase  II  appears  now  required  to 

address  two  situations:  the  interface  of  existing  Burroughs 

MAPS  RJE  hardware  and  software  to  SPLICE  complexes  and  the 

outright  replacement  by  SPLICE  of  existing  MAPS  RJE  hardware 

and  software.   The  former  is  not  addressed  in  the  SPLICENet 

proposal,  but  the  latter  is. 

Current  MAPS  RJE  equipment  consists  primarily  of 

Burroughs  minicomputers  and  peripherals.   Over  the  years, 

this  hardware  has  slowly  been  upgraded  and  standardized 

around  the  B1900  system,  although  older  and  smaller  systems 
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still     exist.       These    systems    can    support    Burroughs    terminal 
concentration,    high    priority    document    printing,    batch 
printing,    card    input/output    operations,    local    disk    and    tape 
archival     storage,    and    data    communications    interface    to    one 
or   more    Burroughs    FEPs    using    the    Burroughs    Poll/Select 
protocol . 

Interfacing    such    Burroughs    B1900    systems    to    a    SPLICE 
complex    may    prove    to    be    a    challenge.       SPLICE    should    have    no 
problem    in    accommodating    the    existing    Burroughs    Poll/Select 
protocol,    although    some   modifications    in    FDC    products   may 
have    to    be   made    to    handle    larger    record    and    block    sizes,    any 
different    characteristics    of    the    B1900    system    itself    as    both 
a    terminal    and    a    concentrator    controlling    up    to    39    other 
Burroughs    terminals,    and    any    unique    data    verification 
techniques    currently    used    to    provide    end-to-end    integrity 
between    host    and    satellite.       SPLICENet    plans    will    also 
require    changes    to    accommodate    this    foreign    host    at    a    SPLICE 
site    (cell)    level.       The    real    challenge    will    be    identifying 
and    making    B1900    Satellite    Activity    Monitor    II    and    SAM    II 
Data    Communications    Handler    software    changes    which   may    be 
required    to    accommodate    the    fact    that    they    are    not 
interfacing    to    a    Burroughs    FEP    and    SDCH    directly.       This 
interface   may    also    require    SDCH    or    other    Burroughs    host 
software   modifications    (i.e.,    MAPS). 

The    original     SPLICE    Phase    II    plans    for    outright 
replacement    of    current    MAPS    RJE    support,    less    the    B1900 
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interface,    still    appear    executable.       The    authors    were    unable 
to    obtain    any    firm    documentation    on    FMSO    SPLICE    Phase    II 
design    and    development.       Questions    on    this    phase    still     to    be 
answered    include: 

1.  in    what    form    will     the    satellite    destined    output 
formats    (i.e.,    compacted    or    uncompacted    and    ASCII    or 
EBCDIC)    going    to    the    SPLICE    Complex    and    to    the    SPLICE 
satellite    be?; 

2.  how    will     the    satellite    operator    interface    to    SDCH    if 
complete    remote    Burroughs    console    capabilities    are    not 
included    in    Burroughs    Pr e-Proc essor? ; 

3.  how   will    host    output    product    formats    be    interfaced    to 
the    TANDEM    SPOOLER    product    on    the    satellite?; 

4.  and    what    changes    are    required    to    Burroughs    host 
programs    to    accommodate    this    new   capability? 

Without    additional    data,    the    authors    can    say    little   more 

aboutthiseffort. 

3.      DLANet    Access 

A  highly  visible  and  critical  companion  logistics 

service  to  NAVSUP  is  the  Defense  Logistics  Agency  (DLA).   In 

that  both  parties  have  recognized  this,  high  level 

agreements  have  been  made  to  permit  organizational 

components  from  both  activities  to  access  the  others'  data. 

For  purposes  of  this  document,  that  means  a  stock  point  user 

at  a  terminal  must  be  able  to  access  three  DLA  systems:  the 

Standard  Automated  Material  Management  Information  System 

(SAMMIS),  the  Defense  Integrated  Data  System  (DIDS)  and  the 

Interrogation  Requirements  Information  System  (IRIS),  while 

a  DLA  terminal  user  must  have  access  to  stock  points'  MSIR, 

RDF,  RSF,  and  Excess  Status  File  (ESF)  data. 
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Although  a  good  policy  decision,  these  interfaces  in 
the  absence  of  DDN85  are  somewhat  complicated  due  to 
hardware,  software,  protocol,  and  geographic  distance 
issues.   For  example,  DLA  activities  use  IBM  hardware  with 
NCR  COMTEN  FEPs  using  tne  Communications  Networking  Software 
(CNS)  to  interconnect  their  IBM  hosts  (DLANet)  as  a  means  to 
provide  their  users  "corporate"  access  to  data  and  systems. 
The  DLA  standard  protocol  is  BISYNC  and  the  standard 
terminal  a  3270  series  or  compatible.   On  the  other  hand, 
stock  points  with  SPLICE  use  TANDEM  and  Burroughs  hardware 
with  a  TANDEM  EXPAND/DDN  X.25  network  planned  to 
interconnect  them.   The  stock  point  standard  protocol  is 
Poll/Select  with  Burroughs  TD/MT  series  terminals  comprising 
the  bulk  of  the  inventory.   Both  systems  have  or  will  have 
network  nodes  CONUS  wide,  but  with  few  within  the  immediate 
V  ic  in  i  ty  of  eac  h  other . 

After  numerous  meetings,  the  technical  details  to 
provide  this  two  way  interface  were  ironed  out.   The  FDC 
SPLICENet  proposal  outlines  the  methods  and  products 
required  to  accomplish  this  [Ref.  105].   The  SPLICE  sites  at 
NSCs  Norfolk  and  Oakland  will  serve  as  stock  point  gateways 
into  DLANet.   At  these  sites,  the  SPLICE  complexes  will 
install  additional  software  and  lines  to  interface  to  DGSC 


Q^DLA  currently  is  not  a  DON  user,  nor  will  it  be  in  the 
immediate  future.   NAVSUP  though  SPLICE  is  a  closed 
community  DON  user,  with  plans  to  go  interoperable. 
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Richmond,  VA.,  and  Defense  Depot  Tracy,  CA.,  respectively, 
for  two  way  system  access. 

Access  to  DLANet  will  be  performed  as  follows. 
TANDEM'S  EM3270  product  will  be  required  so  that  TANDEM 
terminals  can  emulate  IBM  3270  devices.  The  TANDEM  product 
TR3271  will  be  installed  to  permit  a  TANDEM  system  to  appear 
to  an  IBM  system  as  a  cluster  controller.   A  dedicated  data 
communications  line  supporting  BSC  3270  will  connect  the 
TANDEM  system  to  the  appropriate  NCR  COMTEN  for  this  path. 
A  SPLICE  user  will  access  DLANet  only  from  the  SAS  services 
screen  at  either  of  the  gateway  SPLICE  sites.   When 
validated  as  authorized,  SAS  will  interact  with  the  local 
CCP  to  dynamically  configure  an  EM3270  process  (via  EMCOM), 
initiate  a  session  with  the  COMTEN,  and  present  the  user  the 
DLANet  signon  screen.   The  user  may  then  access  the  various 
DLANet  sy stem s/ f i 1 es  as  permitted  by  security  authorization. 

The  gateways  from  DLANet  to  the  SPLICE  sites  is 
slightly  more  complex  and  requires  a  second  BSC  3270  line. 
In  addition  to  the  TANDEM  software  already  mentioned,  two 
additional  products  are  required:  AM3270,  to  provide  support 
for  the  in-coming  3270  line  from  the  NCR  COMTEN,  and  TERM 
INIT/3270,  to  perform  session  services  and  mapping  between 
3270  data  streams  and  the  TANDEM  6530  PATHWAY  format.   There 
is  also  a  new  software  package  required  for  the  NCR  COMTEN: 
the  Multiple  Access  Facility  with  the  Remote  Host  Option 
(MAF/RHO).   This  software  identifies  the  TANDEM  systems  as 
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remote  hosts  which  are  allowed  to  be  accessed  by  the 
remainder  of  the  DLANet  system. 

For  a  DLA  user  to  access  a  SPLICE  gateway,  he  must 
request  access  to  SPLICENet  from  the  ilAF/RHO  option 
selection  at  his  site.   Previously  executed  TERM  IN  IT/3270 
processes  will  have  opened  the  AM3270  processes  and  have 
been  placed  in  a  wait  state.   When  an  AM3270  process 
receives  a  positive  response  to  its  poll  of  its  MAF/RHO 
subdevices,  TERM  INIT/3270  assumes  control  of  the  session 
and  pushes  the  SAS  logon  screen  to  the  DLA  user.   Once 
signed  on,  the  DLA  user  may  transverse  SPLICENet  in 
accordance  with  his  security  access  authorizations. 

The  above  described  DLANet  access  is  currently  in 
the  process  of  being  implemented. 
4.   DON  Access 

Among  its  roles,  the  DON  is  the  mandatory 
telecommunications  interface  for  ADP  systems  and  data 
networks  [Ref.  106].   As  such,  SPLICE  must  interface  to  it 
and  utilize  it  in  support  of  many  NAVSUP  long-haul 
communications  and  interoperability  initiatives.   In 
addition  to  stock  points,  SPLICE  was  also  tasked  to  fulfill 
these  requirements  on  behalf  of  the  ICPs  and  TRIDENT  LDS. 

The  SPLICE  plan  to  interface  to  DON  consists  of  at 
least  two  phases.   A  phased  approach  is  required,  since  it 
was  not  possible  to  obtain  any  of  the  full  suite  of  DOD 
mandated  DDN  protocols  off-the-shelf  in  the  SPLICE 
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procurement.   Also,  the  phased  approached  is  required  since 
various  DDN  project  waivers  permit  users  different  amounts 
of  time  before  they  must  become  interoperable,  while  SPLICE 
must  be  interoperable  to  many  activities  immediately.   The 
two  known  phases  are  described  below.   [Ref  107] 

In  the  first  phase,  SPLICE  will  interface  to  the  ODN 
network  as  a  closed  community.   Under  this  phase,  SPLICE 
sites  will  use  TANDEM  EXPAND  with  a  CCITT  or  basic  X.25  line 
and  host  interface  to  DDN  Interface  Message  Processors 
(IMPs).   The  IMPS  will  use  essentially  dedicated  basic  X.25 
transmission  lines  to  reach  other  SPLICE  nodes.   Without  TCP 
and  IP  and  while  using  basic  X.25  under  EXPAND  within  the 
DDN  backbone,  SPLICE  will  remain  a  closed  community. 

During  this  phase  SPLICE  will  probably  only 
implement  a  stock  point  mail  system,  permit  selected  users 
to  logon  to  other  sites  via  Command  Interpreters,  and  permit 
the  non-DDA  sites  to  pass  DDA  transmission  packages  to  the 
DDA  gateway  site(s).86   nq  plans  have  been  located 
indicating  that  any  "network"  applications  will  be  developed 
during  this  phase.   Gateways  to  and  from  DLA,  ICP,  and  DAAS 
(i.e,  via  a  DDA  gateway)  will  be  used  employing  local  or 
non-DDN  transmission  lines.   Users  and  processes  will  be 
required  to  logon  to  the  gateway  sites  over  the  closed 


86in  the  interim  to  DAAS  using  DDN  on  an  interoperable 
basis,  SPLICE  will  access  DAAS/AUTODIN  I  via  a  gateway  and 
DDA.   See  the  next  section  for  a  discussion  of  DDA. 
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community  EXPAND/X.25  network,  and  then  use  the  various 
gateway  applications  and  processes  from  there. 

In  the  second  phase,  long  haul  interoperable 
SPLICEnet  will  begin  to  be  implemented.   The  original  direct 
EXPAND/basic  X.25  interface  to  the  DDN  IMP  will  be 
supplemented  with  a  FDC  provided  DDN  interface  controller, 
which  will  still  interface  to  the  SPLICE  TANDEM  system  via 
CCITT  X.25,  but  to  the  DDN  IMP  with  either  CCITT  X.25  or  DDN 
Standard  X.25.   The  controller  itself,  made  by  Communication 
Machinery  Corporation,  will  map  CCITT  basic  to  DDN  Standard 
X.25,  as  well  as  have  TELNET,  TCP  and  IP  resident  on  it. 
Revised  FDC  SAS  and  CEM  software  packages  will  also  be 
required  in  this  phase  [Ref.  108]. 

Phase  II  will  permit  either  closed  community  or 
interoperable  DDN  interface  on  a  line.   In  that  two  DDN 
lines  are  planned  at  each  large  SPLICE  site,  both  closed 
community  and  interoperable  lines  can  be  maintained 
concurrently:  the  CCITT  X.25  line  under  EXPAND  for  SPLICE  to 
SPLICE  connectivity  and  the  DQD  Standard  X.25  line  under 
normal  DOD  protocols. 87   pTP  and  SMTP  will  be  implemented  on 
the  TANDEM  processors.   Again,  no  reference  is  made  to  any 
applications  which  will  use  or  support  the  DDN  protocols. 


S^Although  not  addressed  in  the  SPLICENet  proposal,  it 
would  be  advantageous  to  have  EXPAND  work  with  DDN  Standard 
X.25  as  an  option  rather  than  CCITT  X.25.   If  this  is  done, 
the  CCITT  (basic)  X.25  lines  currently  in  use  by  NAVSUP  can 
be  released  with  no  loss  in  SPLI CE- to-SPLI CE  site 
functional ity. 
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It    is    not    clear    from    the    SPLICE    project    documentation    or    the 
SPLICENet    proposal     if    non-SPLICE    DDN    users    who    do    access    a 
SPLICE    site    with    TELNET    will     have    any    SPLICE    resident 
applications    available    to    them.       All    NAVSUP    SPLICE    resident 
applications    are    being    written    for    TANDEM    6530    block    mode 
devices,    not    asynchronous,    scroll    mode    devices,    as    TELNET 
requires.       There    is    also    no    indication    that    any    NAVSUP 
application    will    be    re-written    to    support    such    devices, 
without    some    funding    source.       Some    TANDEM    software    packages, 
like    the    line    editor,    will    be    available    for   mail     interface. 

5.   DAAS/AUTODIN  I  Access 

DAAS  is  an  acronym  for  the  Defense  Automatic 
Addressing  System.   AUTODIN  I  stands  for  the  Automated 
Digital  Network,  Number  I.   Together  they  represent  the 
primary  methods  used  today  to  transfer  military  standard 
(MILSTRIP)  documents  among  logistics  activities  (e.g., 
requisitions,  status,  etc.). 

An  activity  need  merely  batch  all  of  its  military 
standard  documents  together,  regardless  of  destination, 
append  appropriate  header  and  trailer  in  formation , 88  and 
take  this  package  to  the  nearest  AUTODIN  access  point  for 
transmission.   The  AUTODIN  access  point  will  forward  the 
package  to  DAAS,  which  will  then  make  specific  document 


88The  Joint  Chiefs  of  Staff,  Automatic  Digital  Network 
(AUTODIN)  Operating  Procedures  JANAP  128,  of  March  1983  apply 
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distribution    based    on    standard    activity    routing    identifiers. 
Alternatively,    a    site   may    specifically    code    tne   destination 
routing    identifier    for    each    transmission    package    in    order    to 
by-pass    DAAS    and    use    AUTODIN    I    for    direct    site    transmission. 

NAVSUP    stock    points    and    the    ICPs    are   directly 
interfaced    to    AUTODIN    I    for    both    DAAS    access    and    direct 
AUTODIN    I    site    transmissions    using    a    FMSO    developed    system 
called    On-Line    AUTODIN    (OLA).       This    system    is    PE    based    and, 
at    stock    points,    is    connected    to    the    Burroughs    hosts    via 
data    communications    lines    and    interfaces    with    MAPS    software 
(i.e.,    TDS/IDST)    for    package    preparation    and    subsequent 
document   distribution.       An    Univac    494-to-OLA    interface 
ex  i  st s    at    the    ICPs . 

Four    events    have   made    these    interfaces    no    longer 
desirable. 

1.  NAVSUP    wishes    to    phase    out    all    of    their    PE    equipment. 

2.  NAVSUP    wishes    to    phase    out    Burroughs    FEPs,    to    which 
OLA    interfaces . 

3.  The    ICP    Univac    hardware    is    being    replaced    by    IBM 
hardware . 

4.  DDN    appears    now    to    be    the    preferred    method    for 
c omputer- to-computer   data    transmission. 

As    a    result    of    these    events,    NAVSUP    directed    that    the    OLA 

system    be    phased    out    and    replaced    by    a    new    Defense    Data 

Access    (DDA)     system    [Ref    109]. 

DDA    itself    is    planned    in    three    phases    [Ref.    110]. 

Phase    I    will    permit    the    passing    of   military    standard 

messages    in    JANAP    128    header    format    to    only    DAAS    and    receipt 
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of    similarly    formatted    messages    from    DAAS.       The    FMSO 
documentation    appears    to    anticipate    passing    Burroughs 
prepared    messages    to    a    FDC    software    package    on    the    TANDEM 
for    further    distribution.       The    authors    anticipate    this    will 
be    the    FDC    CEM    software    and    CEM    must    handle    getting    them    to 
DAAS.       DDA    audit    capability    will    be    primarily    at    the   message 
level.      Altnough    SPLICE    complex    and    LCN    software    will    get 
transmission    packages    to    the    Burroughs    hosts,    a    MAPS 
software    package,    Transaction    Distribution    System    (TDS), 
will     perform    document    distribution.       The    JANAP    128 
formatting    of   messages    will    continue    to    be    done    on    Burroughs 
via    another    MAPS    software    product,    IDST. 

If    DAAS    is    on    the    DDN    at    the    time    DDA    Phase    I 
software    is    available    and    the    second    phase    of    the    SPLICE    DDN 
interface    is    also    available,    the    actual    message    passing    will 
be    accomplished    via    interoperable    DDN.       If    either    condition 
is    not   met,    some    number    of    SPLICE-DAAS    gateway    sites    will    be 
designated    and    traffic    sent    to    the   gateways    over    the    SPLICE 
DDN    closed    community    subnet.       The    SPLICE    gateway    sites   must 
then    be    interfaced    to    DAAS    itself   via    landlines    to    pass    on 
traffic. 89      DAAS    will     serve    as    the    stock    point    DDN-AUTODIN    I 
gateway,    where    this    function    is    still    required. 


S^The    SPLICENet    proposal     recommends    use    of    the    TANDEM 
EXCHANGE    software    for    this    purpose,    permitting    a    SPLICE 
gateway    site    to    appear    as    an    IBM    2780/3780    Data    Transmission 
Terminal     using    the    BSC    point-to-point    protocol.       The    FMSO 
DDA    FD    mentions    nothing    about    this. 
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Phase    II    of    DDA    will     permit    transmission    of   military 
standard    traffic    to    other    than    DAAS    over    the    DDN.       DDA 
itself   will    determine    if    a    message    should    be    sent    to    DAAS    or 
directly    to    another    on-line    SPLICE    site.       Appropriate 
routing    information    and    messages    will    be    passed    to    CEM,    who 
will     handle    further    transmission.       Transaction    distribution 
facilities    will    be   moved    from    the    Burroughs    to    DDA    itself. 
Audit    capability    will    be    extended    to    include    batch,    message, 
and    transaction    levels. 

Regardless    of    whether    interoperable    DDN    access    is 
available    on    SPLICE,    CEM    will     pass    the   messages    directly    to 
the    addressed    SPLICE    site    using    the    SPLICE    EXPAND/X.25    line. 
The    correspondent    receiving    CEM    will    then    pass    the   message 
to    the    remote    DDA    receiving    module.       If    DAAS    at    this    point 
is    on    DDN    directly,    the   gateways    will    be    eliminated. 

The    third    phase    of    DDA    will     include    DDA    direct 
access    to    the    two    ICPs,    as    well    as    full    DDN    community 
routing.       The    CEM    at    the    sending    site    will    determine    which 
path    to    take:     interoperable    DDN    or    CEM-to-CEM    over 
EXPAND/X.25.       All     ICP    destined    traffic    will    be    sent    over    the 
EXPAND/X.25    line    to    the    applicable    ICPNet   gateway. 

Having    addressed    the    various    requirements    for    inter- 
site    interoperability    and    how    SPLICE    can    satisfy    these 
requirements,    the    area    of    benefits    can    now    be    addressed. 
Shore    based    interoperability    will    provide    three   major 
benef i  ts : 
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1.  improved    supply    information    to    the    user    community; 

2.  more    rapid    transmission    of    logistics    requirements    to 
the    supply    system; 

3.  and    less    manual     intervention    required    to    perform 
logistics   missions. 

These    benefits    will    have    a   direct    affect    on    improving    fleet 

support . 

Existing    MAPS    RJE    activity    access    and    MAPS    RJE    site 

system    replacement    can    provide    the    following    benefits: 

1.  extension    of    the    life    of    existing    MAPS    RJE    equipment, 
thus    deferring    replacement    costs; 

2.  improved    terminal    processing    capabilities    at    the 
satellite    sites    after    SPLICE    equipment    is    installed    in 
terms    of    both    numbers    available    for    use    and    types 
supported . 

3.  improved    local     processing    capabilities    in    support    of 
local    applications    and    the    satellite's    ability    to    use 
SPLICE    complex    resident    applications,    DOA,    and    DON 
after    SPLICE    implementation. 

4.  the    ability    to    eliminate    card    processing    at    satellite 
sites    via    DDA,    UCEPS,    and    other    source   data    automation 
efforts    after    SPLICE    implementation. 

5.  the    ability    to    isolate    satellite    MAPS    RJE    equipment 
and    operations    from    additional    disruption    during    SPAR 
transition    by    using    SPLICE    equipment.       The    additional 
disruption    would    be    in    the    form    of    hardware    and 
software    replacement    in    addition    to    host    procedure    and 
program    changes    that    SPAR    transition    will    require. 

These    benefits    can  directly    accrue    to    tide-water    fleet 

support    activities  enabling    them    to    provide    better    customer 

support    and    to    the  corporation    in    terms    of    better    geographic 

1 og  i  st  ic  s    support . 
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The    ability    to    access    DLA    systems/files    prior    to    their 
DON    interconnection    provides    two    benefits    to    stock    point 
users: 

1.  the  ability  to  obtain  better  management  information  on 
contract  initiatives,  DLA  stock  numbers,  replenishment 
actions,    and    supply    support    actions; 

2.  the    ability    to    more    rapidly    input    update    or    change 
actions   directly    into    the    DLA    system. 

Both    of    these    benefits    will    assist    stock    point    retail 

c ommod i ty/ i tem   managers    who    are    responsible    for   maintaining 

retail     stockage    levels    in    support    of    fleet    customers. 

Both    DON    and    DAAS/AUTODIN    I    access    will    provide 
similar    benefits    to    the    corporation,    the   most    important 
being    the    ability    to    electronically    transmit    and    receive 
information.      The    DAAS/AUTODIN    I    access    provides    this 
ability    in    the    interim    to    all    DOD    activities    being    on    DDN, 
while    also    providing    document   distribution    services,    if 
desired.       The    DDN    access    provides    the    long-term   means    by 
which    the    corporation    will    accomplish    horizontal    and 
vertical    system    integration,    establish    shipboard    to    shore 
logistic    system    integration,    implement    a    corporate 
electronic   mail    system,    and    permit    users    and    processes    to 
commun  ic  ate . 

The    same    comments   made    concerning    the    need    for    intra- 
site    connectivity    migration    to    SPAR    apply    here    to    inter-site 
interoperability.       Many    of    the    systems   mentioned    within    this 
section    will    remain    in    place    for    the    entire    SPLICE    life 
cycle    and    later    be    replaced    by    systems    performing    similar 
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functions  for  which  the  interface  requirements  will  remain. 
While  SPLICE  is  present,  there  should  be  no  need  to  migrate 
or  be  concerned  with  inter-site  interoperability:  SPLICE 
will  provide  for  it.  When  the  time  comes  to  prepare  for 
SPLICE  replacement  within  SPAR,  the  existing  interfaces  and 
lessons  learned  from  SPLICE  should  be  invaluable  tools  upon 
which  to  base  replacement  system  functional  specifications. 

Intra-site  interoperability  supports  or  is  supported 
by  the  following  proposed  SPLICE  objectives:  5,  8,  10,  12, 
15,  16,  19,  20,  21,  22,  23,  25,  29,  32,  33,  and  41." 

The  authors  would  like  to  recommend  the  following  for 
consideration  in  this  area: 

1.  Initiate  a  requirements  study  to  determine  what  are 
existing  and  planned  local  data  communications 
interfaces  to  stock  points,  that  DON  may/will  not 
accommodate.   Incorporate  the  results  into  SPLICE 
project  plans  and  SPLICENet  proposal. 

2.  Revise  the  FMSO  SPLICE  Phase  II  design  and  the 
SPLICENet  proposal  to  account  for  some  Burroughs  MAPS 
RJE  equipment  being  interfaced  directly  to  SPLICE. 

3.  Develop  a  plan  to  replace  all  Burroughs  MAPS  RJE 
equipment  so  interfaced  before  SPAR  implementation. 
If  price  remains  an  obstacle,  consider  substituting 
smaller  TANDEM  systems  or  components  (i.e.,  EXT  or  any 
of  several  other  smaller  entry  level  systems  that  will 
be  announced  by  TANDEM  this  year).   This  is 
particularly  feasible  at  small  MAPS  RJE  sites,  that  do 
little  more  today  than  terminal  concentration, 
transmit  input  documents,  perform  local  programming 
and  for  whom  the  SPLICE  MAPS  site  benchmark  has  little 
practical  workload  bearing  (i.e.,  SUBASE  Pearl 
Harbor) . 

4.  Eliminate  the  need  for  satellite  card  processing  by 
extending  NAVSUP  card  elimination  efforts  (i.e.,  SDA 
and  UCEPS)  and  DDA  to  satellite  sites  on  SPLICE. 
Then,  eliminate  the  card  reader/punch  from  the  SPLICE 
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support . 


and    the    requirement    for    remote    card    equipment 


Attempt    to    reduce    user    input    requirements    to    initiate 
DLA    access    to    only    menu    selections    and    security    sign- 
ons.       The    system    interface    concept    reviewed    by    the 
authors    appears    feasible    but    the    details   must    be 
geared    to    the    GS    4/5    Supply    Clerk    for    use,    not    an    IBM 
systems    programmer. 

Obtain    a    commitment    from    TANDEM    via    FDC    to    support 
standard    X.25    under    EXPAND.       Although    the    Defense 
Communications    Agency    will    attempt    to    block    this, 
retain    the    basic    X.25    lines    until    then. 90 


Ensure    that    FDC    plans    for    DDN    access    under    SPLICENet 
will    not    reduce    SPLICE'S    ability    to    use    existing    or 
planned    off-the-shelf    TANDEM    packages,    such    as 
TRANSFER    or    PS    MAIL,    the    future    TANDEM    SQL    product,    or 
the    future    TANDEM    products    which    will    address 
interconnecting    electronic   mail    systems. 

Develop    an    application    access    support    plan    to    SPLICE 
for    non-SPLICE    systems    and    users.       Include    in    this 
plan,    what    systems,    files,    and    transactions    each 
external    user    will    be    authorized    by    NAVSUP    to    use    and 
the    1 ine/ network/gateway/dev ic e    that    each    will    be 
using.       This    plan    should    then    be    given    to 
FMSO/FDC/DLA/NAVMASSO    to    implement,    where    possible, 
and    require    feedback    to    NAVSUP    as    to    what    is    required 
of    the    user    to    provide    the    requested    access    if    not 
immediately    possible. 91 

Ensure    that    FMSO    and    FDC    are    both    working    from    the 
same    set    of   design    plans    for    DDA,    particularly    in 
terms    of    internal     site    interface.    From    the    limited 
documentation    held    by    the    authors,    it    is    unclear    if 
FMSO    is    aware    of    the    details    of    SPLICENet    in    the    area 
of    DDN/DAAS    interface.       Perhaps    the    interface    to    and 
from    DDA    to    CEM    will    be    as    transparent    as    the    FMSO 


90conv er sa t i 0 ns    with   mid-level    Defense    Communications 
Agency    personnel     indicated    that    they    plan    on    removing    the 
basic    X.25    lines    from    SPLICE    sites    as    soon    as    TCP/IP    is 
implemented    on    SPLICE    or    until    SPLICE'S    next    DDN    waiver 
expires,    whichever    is    sooner. 


91of    particular    interest    here    is    the    DDN    user    on    a 
terminal    who    "TN's"    to    a    SPLICE    site    and    finds    that    no 
logistics    services    are    available    to    him    since    they    were 
designed    for   more    intelligent    block   mode   devices. 
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documentation    assumes.       However,    from    the    experience 
of   the    authors,    such    transparent    interfaces    are    few    in 
number,    and    usually    require   government    changes    to 
im  pi  em  en  t . 

This    concludes    the    discussion    of    inter-site    and    shore 

based     interoperability.       Shipboard     interoperability    will 

next    be    addressed. 
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VIII.   SHIPBOARD  TELECOMMUNICATIONS  INTEROPERABILITY 

A.   CHAPTER  OVERVIEW 

This  chapter  will  address  the  area  of  shipboard  to  shore 
establishment  interoperability  in  terms  of 
telecommunications  and  the  Shipboard  Nontactical  Automated 
Data  Processing  (SNAP)  programs.   Two  of  the  sections 
presented,  Background  SNAP  I  and  Background  SNAP  II,  are 
provided  for  background  information,  if  the  reader  is 
unfamiliar  with  the  SNAP  systems  that  are  being  installed  on 
all  major  ships  and  their  application  areas.   If  the  reader 
is  familiar  with  the  functions  of  SNAP  I  and  II,  bypassing 
these  background  sections  is  recommended.   The  Naval  Air 
Logistics  Command  Management  Information  System  (NALCOMIS) 
is  also  discussed  in  this  chapter  as  it  is  being  deployed  on 
ships  for  aircraft  maintenance  and  repair  at  the  afloat  IMA 
level.   NALCOMIS  runs  on  the  same  computer  hardware  as  other 
SNAP  I  applications,  the  Honeywell  DPS6  series. 

The  authors  intent  in  this  chapter  is  to  show  how  the 
"great  leap  forward"  in  automating  the  shipboard  environment 
would  benefit  from  interfacing  via  telecommunications  to 
SPLICE  and  from  SPLICE  to  the  outside  world,  rather  than  the 
mailed  or  hand  carried  magnetic  tape,  card  output,  and 
AUTODIN  I  system  interfaces  currently  planned  for  use  while 
ships  are  in  port . 
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B.   BACKGROUND  SNAP  I 

SNAP    I    is    planned    for    use    in    selected    shore 
establishments    and    on    large    ships.       The    primary    purpose    of 
SNAP    I    is    a    replacement    system    for    the    obsolete    Univac    U1500 
computer    systems    currently    installed    on    ships    of    type    CV, 
CVN,    AFS,    AS,    AD,    AR,    LPH,    and    LHA.       The    Univac    U1500    is    a 
batch    tape    oriented    system    that    is    early    1960's    technology. 
This    system    supported    financial,    inventory,    requisition,    and 
intermediate   maintenance   management    system    applications. 

The    SNAP    I    computer    is    based    on    late    1970's    technology, 

manufactured    by    Honeywell,    and    designated    as    a    DPS5 

(series).       The    SNAP    I    system    is    to    give    the    above   mentioned 

large    combatants    and    selected    shore    support    activities    a 

real     time,    disk,    and    CRT    oriented    ADP    system.       The    overall 

concept    of    the    new    system    is    detailed    in    SNAP    II    Management 

Guide    [Ref.     Ill]    as: 

To    improve    fleet    readiness    and    provide    a    standard 
automated    information    system    (AIS)    to    be    used    by    all 
fleet    operational    and    direct    units,    afloat    and    ashore. 
Inherent    to    this    concept    is    the    premise    that    all     SNAP 
functional    requirements,    and    particularly    the   machine 
interface    requirements,    are    identical     for    all     ship 
types . 

SNAP    I    will     provide    ADP    support    for    not    only    the    batch 

oriented    jobs    that    the    U1500s    once    performed,     including    the 

movement    of    these    processes    to    disk,    it    will     also    convert 

many    of    these    applications    to    an    on-line    CRT    orientation. 

In    addition,    it    will     automate    many    of    the    current   manual 

administrative    and    logistic    shipboard    functions,    thereby 
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reducing    the    paperwork    burden    on    shipboard    and    staff 
personnel    and    allowing    them    to    concentrate   more    on    the 
quality    of    the    information    that    is    required    to    be    provided 
to    shore    establishment    commands. 

SNAP    I     is    divided     into    to    five    functional     areas    for 
automation.       These    ares    are:    Adminstration    (ADM), 
Intermediate    Maintenance    Management    System    (IMMS),    Ownship 
Maintenance    Management    System    (OMMS),    Source    Data    System 
Afloat    (SDSA),    and    Shipboard    Uniform    Automated    Data 
Processing    (SUADPS).         A    brief    listing    of    the    functions 
provided    in    each    area    follows: 

1.  ADM    -    maintains    management    of    Shipboard    personnel 
assignment,    career    development    and    retention,    health/ 
administration/morale    subsystem    management,    personnel 
qualification   management,    retention    program 
management,    ship's    bill    management,    security    force 
management,    schools   management,    visitor    control 
management,    and    ad    hoc    query. 

2.  IMMS    -    maintains    an    automated    Current    Ship's 
Maintenance    Project    (CSMP)     file    at    the    Intermediate 
Maintenance    Level     (IMA)    which    provides    the    following 
functions:    plan    work    requests,    screen    work    requests, 
create    work    packages,    track    job    progress,    schedule 
jobs    and    key    events,    validate   maintenance    requests, 
and    ad    hoc    query. 

3.  OMMS    -    will    provide    the    following    functions: 
management    of   current    ship's   maintenance    project 
(CSMP),    trouble    log    processing,    equipment 
configuration    and    logistics    support,    work    package 
processing,    management    reports,    CSMP    reporting 
process,    and    subsystem    manager    functions. 

4.  SDSA    -    is    designed    to    provide    the    following    functions: 
disbursing    and    personnel    area    administrative    and    pay 
event    reporting,    pay    and    fiscal    management,    SDSA 
system   management    information. 

5.  SUADPS    -    is    to    provide    the    following    functions:    on- 
line  data    entry/error    processing,    master    record    file 
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query,    substitute    information,     interactive   material 
request,    picking    tickets,    Direct    Turnover    Over    (DTO) 
requisition    release,    warehouse    processing. 
Consolidated    Shipboard    Allowance    List    (COSAL) 
processing,    supply    effectiveness    reporting,    financial 
man ag emen t/ Budg et    Optar    reporting,    and    Global 
r eo  rd  er / of f 1 oad . 

From    this    extensive    listing     it    can    be    seen    that    SNAP    I     is 

designed    to    automate   many    of    those    shipboard    administrative 

and    logistic    functions    that    have    been    performed    manually    or 

in    a    batch   mode    in    the    past. 

All     interfacing    to    and    from    this    shipboard    systems    is 

planned    to    be    accomplished    via   magnetic    tapes,    punched 

cards,    or    through    a    paper    tape    medium    to/from    the    AUTODIN    I 

system.       Currently,    the    SNAP    activities    which    require    an 

automated    interface    with    external     systems    are    as    follows: 

submission    of    Material    Maintenance    Management    System    (3-M) 

data    (OPNAV    4790/2K),    receipt    of    bulk    Coordinated    Shipboard 

Maintenance    Project    (CSMP)     input,    submission    of    requisition 

and    budget    OPTAR   data,    receipt    of    requisition    status    data, 

receipt    of    full     and    supplemental    COSAL    update    tapes,    and 

automated    Allowance    Parts    Lists    (APL)    deletion    and 

ree stabl i shment .       A   more    in    depth    discussion    of    external 

interfaces    is    provided     in    [Ref.     112]. 

Even    the    currently    planned    off    ship    interface   methods 

listed    above    are    seen    as   major    improvements    in    the    accuracy 

and    timeliness    of    configuration    and    logistics    data    movement. 

If    a   more    state-of-the-art    interface   method    was    available, 

SNAP    I    sponsors    would    be    anxious    to    pursue    it. 
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C.   SNAP  I  SUPPORT  APPLICATION  INTERFACES 

The  currently  planned  SNAP  I  to  shore  establishment 
interfaces  require  that  when  a  ship  is  in  port  a  physical 
transfer  of  tape  media,  punched  cards,  or  paper  forms  be 
routinely  done  in  order  to  transmit  or  receive  any 
information.   An  example  from  the  requisition  input  area 
will  be  used  to  demonstrate  this. 

The  submission  of  requisitions  into  the  supply  system  is 
now  accomplished  in  a  number  of  ways.   First,  submission  may 
be  accomplished  by  physically  routing  a  tape  of  MILSTRIP 
formatted,  card  image  requisitions  to  the  local  NSC  for 
processing.   Such  a  tape  submission  is  not  only  wasteful  of 
physical  sailor  effort  in  delivery,  it  wastes  NSC  manpower 
in  handling,  and  must  also  be  converted  before  the  NSC's  can 
read  the  data,  since  the  data  formats  are  in  many  cases 
incompatible.   This  can  result  in  requisition  processing 
delays  of  up  to  three  days. 

In  other  cases,  punched  cards  are  used  as  the  primary 
means  of  delivering  requisitions  to  the  NSCs.   Besides  being 
equally  wasteful  of  manpower  in  performing  delivery,  card 
processing  is  obsolete  technology  and  is  wasteful  of  both 
shipboard  and  NSC  customer  service  and  operations  manpower, 
particularly  since  this  method  requires  very  old  card 
equipment  to  be  maintained  and  made  to  function  properly. 

In  the  case  of  high  priority  requisitions,  a  manual 
paper  requisition  form  is  often  prepared  and  hand  carried  to 
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the    NSC,    where    it   must    be    data    transcribed    prior    to 
processing.       This    process    in    not    only    wasteful    of    shipboard 
personnel     time,    it    requires    duplicate    data    entry    efforts, 
thereby    adding    to    the    possibility    of    error    introduction. 

Several    of    the    NSC's    have   developed    on-line    capabilities 
to    input    requisitions    via    separate    telecommunications 
terminals    installed    on    ships    while    they    are    in    port.       For 
example,    NSC    San    Diego    uses    what    it    calls    the    Fleet    On-Line 
Inquiry    and    Requisitioning    System.      This    system    consists    of 
a    12"    monitor    and    processor    with    al pha/ numer i c    keyboard 
(i.e.,    a    Burroughs    compatible    CRT)    and    an    80    column    printer 
connected     into    their    Burroughs    host    via    telecommunications. 
The    telecommunications    hookup    is    a    2-wire    single    port   modem 
and    a    registered    connecting    device.       Since    this    system 
requires    duplicate    data    entry    (i.e.,    once    on    the    shipboard 
system    and    once    on    the    NSC    terminal)     and    human    transcription 
of    computer    created    requisitions,    only    high    priority 
requisitions    are    processed    in    this    way.       This    system    also 
allows    users    to    query    local     stock    availability,    obtain 
requisition    status,    input    requisition   modifiers,    and    perform 
requisition    follow    ups. 

The    system    installed    at    San    Diego    and    similar    systems 
installed    at    other    NSCs   do    perform    the   job    of    allowing    fleet 
units    to    input    high-priority    requirements    and    receive    status 
of    the    requisitions    submitted    to    the    NSC    on    a    real     time 
basis.      However,    it    requires    additional    telecommunications 
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workload  for  the  NSC's  Burroughs  hosts  and  it  has  done 
nothing  to  improve  the  submission  of  large  requisition  drops 
(i.e.,  tapes  or  cards). 

What  is  required  in  this  area,  as  well  as  in  all  other 
shore  establishment  data  interface  areas,  is  to  have  an  on- 
line, high  capacity  interface  capability  between  the  SNAP  I 
computer  systems  and  the  logistics  system  to  obtain  access 
to  the  NSCs  and  other  shore  based  facilities.   In  the 
opinion  of  the  authors,  the  SPLICE  system,  particularly  with 
SPLICENet,  can  not  only  handle  (or  expand)  the  existing 
number  of  shipboard  single  terminal  interconnections  to  the 
NSCs,  but  it  can  also  provide  other  system  access  (non-NSC), 
as  well  as  higher  capacity  links  or  multiple  links  to  enable 
the  passing  of  large  data  packages. 

The  problem  of  shipboard  interface  to  SPLICE  is  two 
pronged.   First,  shipboard  units  have  to  be  provided  access 
to  a  SPLICE  site.   Second,  mechanisms  must  be  available  at 
the  SPLICE  sites  to  allow  for  sh i pboard- to- shore 
establishment  interoperability  and  permanent  account  space 
or  mailbox  storage. 

The  changes  required  in  the  SNAP  I  system  to  provide 

access  or  establish  SPLICE  system  connectivity  were  detailed 

in  a  meeting  held  at  FMSO  on  2  August  1984  and  they  are  as 

f ol  1  ows  :  • 

1.   addition  of  a  Synchronous  Communications  Line  Adapter 
board,  to  be  resident  on  the  Honeywell  processor 
requiring  data  communication  access  (requires  a  SNAP 
contract  modification). 

209 


2.  addition  of  the  PF/3271  (BSC)  software  package,  to  be 
resident  on  the  Honeywell  processor  requiring  data 
communications  access  (also  requires  a  SNAP  contract 
modification) . 

3.  Government  programming  of  "user  exits"  from  tne 
PF/3271  software  (provides  a  presentation  layer  for 
the  application  process  to  pass  data  sets). 

4.  Training  of  FMSO  or  NAVMASSO  environmental  personnel 
in  the  above  so  that  they  can  program  the  "user 

ex  its." 

In    addition    to    these    enhancements    to    the    SNAP    I    system, 
the    SPLICE    system    will    require    "peer"     presentation    and 
application    processes    to    interface    with    the    SNAP    I 
computers,    as    well    as    6100    communications    subsystem    ports 
available,    capable    of   dealing    with    BISYNC    lines.       This 
higher    speed    land    line    interface    also    requires    the    use   of 
quality,    dedicated    phone    lines,    with    synchronous    modems    at 
either    end,    for    each    SNAP    system    on    the    pier. 

If    this    BISYNC    dedicated    line    service    cannot    be   made 
available    for    pier-side    use,    then    the    SNAP    I    sites    could 
alternatively    implement    a    dial-up   modem    option    to    interface 
to    SPLICE.       SNAP    I    Honeywell     systems    can    be   directly 
connected    to    a    Rixon    modem    (i.e.,    R212A)     to    accomplish    this 
(available    from    the    SNAP    I    contract)    with    user    written 
asynchronous    interface    software    to    permit    the    Honeywell 
system    console    or    a   designated    terminal     to    act    as    a    remote 
asynchronous    terminal     to    the    SPLICE    host.       No    off-the-shelf 
software    package    was    located    by    the    authors    which    could 
perform    this    function. 
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A    second    alternative    would    be    the    use    of   one    of    the    SNAP 
I    system's    smart    term i n al s/ PC s    (i.e.,    Z-150's)     to    download 
data    to    be    transmitted    to    the    PC's   disk    from    the    Honeywell 
system,    using    a    Honeywell     provided    software    package    (i.e., 
Microsystem    VIP    Emulation).       When    all    data    is    on    the    PC,    the 
user    would    shift    to    a    stand-alone    PC    operating    mode;    dial-up 
the    local    SPLICE    site    using    a    local     phone    line/asynchronous 
communications    package    and    sign-on    to    SPLICE    via    SAS    to 
process    transactions    or    pass    data    as    required. 

Assuming    that    SPLICE    system    connectivity    has    been 
provided    at    some    SPLICE    site    via    one    of    the    methods    proposed 
above,    the    second    problem,    providing    shi pboard- to- shore 
establishment    interoperability    can    now    be    addressed.       There 
are    three    aspects    to    this    problem:    local     processing,    AUTODIN 
interface,    and    DON    interface. 

Once    the    shipboard    user    has    passed    security    and    signed 
onto    a    SPLICE    site,    what    can    be    processed    locally    via    a    SNAP 
I    terminal    or    process    will    depend    on    the    processing 
functions    performed    at    the    SPLICE    site.       In    the    case    of    a 
NSC,    a    full    range    of    logistics    functions    as    well    as    other 
system    interfaces   may    be    locally    available.       In    the    case    of 
a    user    signing    on    to    a    NARDAC    or    NARDAF    SPLICE    site    not 
running    UADPS-SP,    the    user    might    have    to    use    SPLICENet    to 
access    a    SPLICE    site    processing    UADPS-SP    to    obtain    full 
logistics    functionality.         Assuming    that    the    user    has 
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signed-on  to  a  logistics  capable  site,  at  least  the 
following  processing  may  be  accomplished: 

1.  input  of  high  priority  requisitions. 

2.  input  of  bulk  requisition  packages  generated  directly 
from  the  SUADPS-RT  system  onboard  the  ships.   This 
would  eliminate  the  delay  and  wasted  man  hours  of 
having  to  convert  magnetic  tapes  to  a  format  capable 
of  being  read  by  the  NSC's  system,  reduce  the  need  for 
obsolete  card  equipment  on  both  systems,  and  would 
also  eliminate  the  need  to  enter  a  requisition  more 
than  once. 

3.  requisition  status,  stock  status,  stock  management 
data  inquiries  using  either  SPLICE  Burroughs  pass 
through  or  the  SPLICE  resident  applications  including 
replicated  files.  This  would  reduce  the  number  of 
phone  calls  that  are  received  at  the  NSCs  for  status 
of  parts  ordered,  requests  for  stock  management  data, 
and  requests  for  current  stock  assets  on-hand. 

4.  receive  status  back  for  inputs  submitted  for  direct 
input  to  SNAP  I  processes. 

5.  use  of  either  SPLICE  TANDEM  TRANSFER/PS  MAIL  and 
TANDEM  editors  or  DDN  mail  and  editors. 

6.  upload  or  download  of  files  to  and  from  the  SPLICE 
system.  These  files  could  be  local  status  outputs 
from  NSC  batch  processes,  a  series  of  user  queries 
captured  to  disk,  MTIS  inquiries,  or  similar  actions. 

The  second  part  of  sh i pboard- to- sho re  establishment 

interoperability  concerns  AUTODIN  I  processing.   Today 

shipboard  units  receive  the  majority  of  their  requisition 

status  via  AUTODIN  I  cards  or  tapes  which  must  be  input  to 

SNAP  I  processes  on  a  batch  basis.    The  following  describes 

how  the  status  updates  of  requisitions  could  be  forwarded  to 

the  ships  in  a  more  timely  manner  and  the  amount  of  Naval 

message  traffic  generated  for  status  of  high  priority 

requisitions  could  be  reduced  using  SPLICE: 
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1. 


2. 


A  system  that  is  in  development  now  will  permit  both 
SNAP  I  and  SNAP  II  systems  to  receive  their  logistics 
MILSTRIP  messages  from  the  AUTODIN  system  in  an  on- 
line manner  instead  of  the  current  hard  copy  formats, 
if  certain  changes  are  made.   As  previously  discussed, 
DDA  is  a  NAVSUP  planned,  major  replacement  of  the 
existing  PE  based  On-Line  AUTODIN  (OLA)  system  being 
used  at  stock  points.   When  DDA  is  implemented,  all 
stock  points  and  ICPs,  as  well  as  any  other  SPLICE 
site  which  have  implemented  DDA,  could  have  the 
capability  to  interface  with  other  sites  for  passing 
and  receiving  logistics  traffic  directly  or  using  the 
DAAS  system  as  a  switch  between  AUTODIN  I  and  DON. 

SPLICE  is  to  be  implemented  at  all  the  NARDACs  and 
NARDAFs.   If  NAVDAC  would  agree  and  be  funded  to  have 
the  NARDACs  and  NARDAFs  to  become  the  DDN  hosts  for 
shipboard  users  via  their  SPLICE  systems,  the 
following  could  occur:  DDA  could  be  implemented  at 
each  NARDAC  and  NARDAF;  DAAS  would  record  each  ships 
address  as  being  at  an  appropriately  located  NARDAC  or 
NARDAF  and  forward  all  AUTODIN  traffic  for  the  units 
there;  DDA  would  process  DAAS  inputs  for  the  ships  and 
segregate  transmissions  into  separate  shipboard 
accounts  or  mailboxes  at  the  NARDACs  or  NARDAFs. 
Using  the  download  procedures  described  previously 
under  local  processing,  these  files  could  be  received 
shipboard  and  input  into  SNAP  I.   Ships  could  also 
reverse  the  process  and  send  their  traffic  out  over 
DDA  to  DAAS  and  then  through  AUTODIN  I. 

As  previously  indicated,  the  authors  envision  a  system 
that  would  allow  the  users  to  be  either  directly  connected 
or  dial-up  connected  to  their  host  NARDAC  or  NARDAF  SPLICE 
system  and  be  able  to  access  their  pre-established  account 
or  mail  box  to  pull  down  existing  traffic  or  input  new 
traffic.   In  this  way,  the  process  of  receiving  AUTODIN 
traffic  via  mail  or  tape  in  card  format  or  Naval  message 
format  could  be  eliminated  during  the  time  a  ship  is  in  port 
or  in  a  local  operations  status. 

The  final  area  of  shi pboard- to- shore  establishment 
interoperability  is  DDN  access  and  usage  itself.   There  are 
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three  aspects  to  this.   First,  the  shipboard  units  must  have 
a  shore-based  DDN  host  site  available  to  serve  as  their  data 
repository  when  they  are  not  in  port.   The  authors  have 
recommended  the  use  of  SPLICE  NARDACs  and  NARDAFs  sites  for 
this  role.   Second,  once  the  ship  has  signed  on  to  a  SPLICE 
node,  it  must  be  able  to  have  available  to  it  the  full  range 
of  DDN  protocols  for  interoperability  outside  of  the 
logistics  community.   SPLICE  plans  to  provide  this  under 
SPLICENet.   Third,  the  shipboard  user  should  also  have 
access  to  portions  of  the  SPLICENet  which  will  provide 
interface  among  NAVSUP  customers  through  SPLICE  TANDEM 
EXPAND/X.25  facilities,  and  which  also  provides  interface  to 
ICPNet  and  DLANet. 

If  the  above  mul ti -  pro ng ed  proposal  were  adopted,  a 
method  would  exist  for  inputting  any  shipboard  data  to  any 
shorebase  location  via  SPLICENet  (i.e.,  providing  access  to 
DDN,  DDA,  ICPNet,  and  DLANet)  or  vice  versa.   With  this  in 
place,  other  shipboard  systems  could  also  take  full 
advantage  of  it.   For  example,  shipboard  financial  documents 
and  returns  must  be  submitted  to  and  interfaced  to  IDAFMS. 
This  proposed  NARDAC  and  NARDAF  DDA  interface  or  the  fully 
DOD  interoperable  SPLICE  DDN  interface  using  FTP  could  be 
used  to  meet  this  shipboard  interface  requirement  to  IDAFMS. 

The  SDSA  project,  in  support  of  the  SDSA  subsystem  that 
is  to  be  run  on  the  SNAP  I  computer,  is  the  functional 
sponsor  that  has  most  aggressively  pursued  the  ability  of  a 
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ship    in    port    to    be    able    to    transfer    its    pay    and    personnel 
data    to    the    shore    based    SDSA    subsystem,    in    a    real-time   mode. 
Data    submission    is    currently    done    by    magnetic    tape.       The 
delays    caused    by    the   mailing    of    the    tapes    becomes    very 
wasteful     in    the    amount    of    transactions    that   must    be 
overridden    on    LES's    by    the    local    disbursing    officers.       The 
average   delay    from    a   mailing    is    13    days    and    27%    of    the 
changes    submitted    must    be    overridden    by    the    local    disbursing 
officers    [Ref .    113] . 

The    direction    that    the    SDSA    program   manager    is   moving 
toward    is    that    of    using    a    phone    link    to    some    unspecified    DON 
connection    while    the    ship    is    in    port    to    reach    the    two    end 
activities,    the    Naval    Finance    Center    Cleveland    and    the    Naval 
Personnel    Command,    Washington.      This    proposal    provides    that 
"unspecified"    connection. 

Since    a    connection    to    the    DDN    can    be   made    with    the 
SPLICE    computer,    the    proposed    interface    would    reduce    the 
need    of    the    extra    line    to    service    solely    the    SDSA    input    from 
the    SNAP    I    computer.       Since    the    ship   can    support    only    so 
many    phone    lines,    it   makes    sense    to    combine    all    the 
electronic    output    into    one    line    and    machine.       The    connection 
should    be    from    the    SNAP    I    computer    to    a    local     SPLICE    system. 
SPLICE    in    this    case    would    be    used    as    a    connection    to    the    DDN 
for    transfer    of    the    information    from    the    ship    to    the 
receiving    activities    DDN    files,    account,    or   mail    box.       If 
on-line    SDSA    shipboard    terminal    access    is    also    desired,    the 
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DDN    TELNET    protocol    will    be    available    from    SPLICE    to    permit 
Shipboard    users    the    ability    to    "TN"     to    the    SDSA    shored    based 
ho  st ( s)     and    sign    on. 

The    ships    could    also    use    the    SPLICE    connection    and 
SPLICENet    to    logon    to    ICPNet    and    download    COSAL    changes 
and/or    update    the    ship's    configuration    information    on    SPCC's 
Weapons    System    File    (WSF).       The    processing    of    COSAL    changes 
and    the    submitting    of    ships    configuration    changes    had    been    a 
manual    process    until    the    installation    of    the    SNAP    I 
computers.      This    process    is    now    served    by    an    automated    data 
base    onboard    ship    that    is    updated    periodically    by    magnetic 
tape    input.       The    inputs    to    this    process    come    from    the    WSF 
ma  in  ta  i  ned    by    SPCC. 

Since    SPCC    is    a    user    of    SPLICENet,    it    seems    only 
sensible    that    instead    of    waiting    for    a    quarterly    tape   dump 
of    COSAL    changes    to    be   mailed    to    the    ship,    an    on-line 
facility    using    SPLICE    as    the    backbone   could    be    utilized    to 
forward    these    changes.       In    this    way    a    ship    upon    arrival     in 
port    could    connect    to    the    local     SPLICE    site    through    the 
proposed    shipboard    SPLICE    interface    and    then    on    to    the    DDN 
to    connect    to    the    SPLICE    computer    at    SPCC    from    which    ICPNet 
access    is    available.       The    ship    could    then    download     its    COSAL 
changes    to    the    remote    SPLICE    site,    FTP    applicable    changes    to 
its    local    SPLICE    DDN    host,    and    finally    download    the    changes 
to    its    SNAP    system    or    intelligent    terminal.       In    this   manner 
the    shipboard    user    could    receive    his    COSAL    changes    that 
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would    be    held     in    read-only    files    at    SPCC,    waiting    for    him    to 
retrieve    them.       This    seems    to    the    authors    to    be    a   more 
expedient    and    efficient   method    for   disseminating    the 
critical    logistical     support    information    that    is    contained     in 
the    quarterly    changes    tapes. 

All    of    the    above    systems    are    looking    at    either    having 
their    own    shipboard    interface    or    terminals    to    transmit 
information    to    and    from    ships.       By    using    a    single    SPLICE 
interconnection,    the    need    for   multiple    lines    to    the    ship    and 
the    confusion    and    trouble    of   dealing    with    them    would    be 
reduced    or    eliminated. 

The    feasibility    of    using    such    an    approach    for    shipboard 
connectivity    has    already    been    demonstrated.       Currently,    a 
Submarine    tender    located    in    Europe    is    using    MINET,    with    a 
link    to    the    DDN    and    a    Bulk    Media    Terminal,    to    transfer 
machine    readable    information    across    the    packet    networks 
[Ref.    114].       In    this    case    the    tender    is    sending    requisitions 
to    a    stateside    DDN    host,    with    the    Poseidon    Material    Office, 
Atlantic    (PMOLANT)     as    the    intended    recipient.       PMOLANT    then 
accesses    the    DDN    host    via    a    dial-up    to    a    TAC    from 
Charleston,    S.C.    and    receives    the    requisitions    or    sends 
status    by    use    of    the    mail     facility    on    the    DDN. 
Justification    for    this   method    lies    in    the    reduction    of 
system    handling    time    and    of    transmission    delays    which    would 
occur    using    the    AUTODIN    system    or    the    extensive   manual 
effort    required    for   message    transmission    alone.      With    this 
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system,  requisitions  can  be  sent  and  received  in  as  little 
as  6  hours  from  start  to  finish  [Ref.  114].   The  proposea 
SPLICE  implementation  could  provide  similar  services  and 
benefits  to  all  SNAP  I  users. 

The  final  area  that  will  be  addressed  is  how  SNAP  I 
tactically  supports  or  can  be  made  to  better  support  the 
proposed  SPLICE  objectives,  thereby  supporting  previously 
presented  corporate  and  project  goals  and  strategies.   SNAP 
I  directly  supports  and/or  is  supported  by  the  following 
SPLICE  project  objectives:  12,  15,  16,  19,  21,  22,  33,  and 
35. 

There  are  several  recommendations  the  authors  have  for 
possible  enhancements  to  SPLICE/SNAP  I  that  will  enable  them 
to  provide  greater  support  or  benefit  to  the  corporation  and 
to  the  Nav  y  as  a  whole: 

1.  Investigate  and  test  the  so f twar e/ hard  war e  to 
support  the  SNAP  I  telecommunications  interface  to 
the  SPLICE  system  to  allow  for  both  on-line 
interaction  and  bulk  file  transfer  to  the  logistics 
system  using  the  synchronous  interface. 

2.  Investigate  and  test  the  software  to  support  the  SNAP 
I  user  interfaces  to  the  SPLICE  system  via  the 
Honeywell  host  itself  or  a  smart  terminal/PC  installed 
on  SNAP  I  ships  and  a  modem  using  an  asynchronous 
line.   Either  of  these  interfaces  would  provide  for 
both  shipboard  on-line  inquiry  and  bulk  file  transfer 
capabilities  using  SPLICE  or  other  supported  terminal 
emulation  software  such  as  the  MicroGate  6530. 

3.  Investigate  the  possibility  for  SPLICE  providing  the 
gateway  to  DDN  for  shipboard  users  using  NARDACs  and 
NARDAFs  as  hosts.   This  would  provide  shipboard  access 
and  system  interoperability  necessary  for  systems  such 
SDSA,  IDAFMS,  and  COSAL  updates. 
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4.  Investigate  the  possibility  of  SPLICE  being  the 
shipboard  access  to  AUTODIN  I  via  a  DDA  interface  at 
the  NARDACs  and  NARDAFs.   This  includes  the 
establishment  of  SNAP  I  ship  DDN  accounts  or 
electronic  mail  boxes  there.   This  would  allow  all 
SPLICE  users  and  DDN  users  the  ability  to  send 
information  electronically  to  the  ships.   Data  such  as 
COSAL  updates,  Disbursing,  Financial,  and  Personnel 
data  could  then  be  passed  in  this  manner  on-line. 

5.  See  the  proposals  in  Chapter  IV  for  shipboard 
interfaces  to  SPLICE  for  use  of  REP  FILES  and  MTIS 
processing  and  the  Chapter  VI  proposal  for  IDAFIPS 
OPFORCES  interface. 

This  completes  the  discussion  of  SNAP  I/SPLICE 

interface.   SNAP  II  interface  will  next  be  addressed. 


D.   BACKGROUND  SNAP  II 

SNAP  II  is  the  small  ship  equivalent  of  SNAP  I.   It  is 
based  on  a  Harris  computer  system  that  is  configured  to  use 
the  same  type  data  files  as  the  SNAP  I  computer  to  promote 
interchange  ability  of  data.   The  goal  of  SNAP  II  is  very 
similar  to  that  of  SNAP  I's:  to  provide  the  maximum 
automated  interface  possible  with  other  fleet  and  shore 
based  automated  information  systems  (either  on-line  or  off- 
line) or  activities  and  to  require  minimal  supply, 
maintenance,  and  training  support.   The  SNAP  II  Shipboard 
Management  Overview  Guide  calls  for  the  system  to:  [Ref. 
Ill] 

Provide  each  ship  with  a  fully  automated  logistics 
management  system  that  interfaces  with  the  Weapons 
System  File  (WSF)  and  all  other  shore  data  bases. 

SNAP  II,  like  SNAP  I,  replaces  most  of  the  manual 

systems  onboard  the  ships  by  combining  the  information  that 
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they  use  into  a  common  data  base.   This  data  base  is  used  to 
produce  internal  reports  and  data,  as  well  as  reports  for 
off  ship  use.   SNAP  II  has  five  major  subsystems:  System 
Management  Subsystem  (SMS),  Maintenance  Data  Subsystem 
(MDS),  Supply  and  Financial  Management  (SFM),  Administrative 
Data  Management  (ADM),  and  Mobile  Logistics  Support  Force 
(MLS).   A   general  description  of  each  follows: 

1.  SMS  is  concerned  with  the  management  of  the  computer 
and  the  data  base  and  has  little  need  for  outside 
interface  other  than  controlling  the  output  devices 
for  other  functions. 

2.  MDS  provides  the  on-line  interactive  3-M  system  which 
needs  to  communicate  with  the  IMMS  and  CSMP  system  on 
SNAP  I  computers.   The  interface  to  this  system  for 
input  and  output  off  the  ship  is  magnetic  tape. 

3.  SFM  is  an  interactive  system  which  supports  supply 
control,  requisition  processing,  inventory  management, 
COSAL  maintenance,  and  financial  management  functions. 
This  function  needs  to  interface  with  outside  sources 
both  SNAP  I  and  IDA.   The  present  plans  call  for 
magnetic  tape  interfaces. 

4.  ADM  is  to  support  the  sh i p- i n ter nal  Manpower 
management  as  well  as  SDSA  which  has  numerous  off  ship 
interfaces  to  be  maintained. 

5.  MLSF  is  an  automated  data  processing  system  that 
supports  replenishment  functions  on  SAC  224  accounting 
ships. 

At  times,  a  function  may  utilize  more  than  one  subsystem 

when  entering  or  extracting  data. 

E.   SNAP  II  SUPPORT  APPLICATION  INTERFACES 

SNAP  II,  as  implemented,  has  dramatically  reduced  the 
amount  of  manual  effort  required  to  provide  the  information 
and  documentation  that  is  needed  to  perform  the  support 
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administration    and    logistic    functions    necessary    onboard 
small     ships.       In    that    the    inputs    and    outputs    of    the    two 
systems    are    similar,    SNAP    II    could    benefit,    in    much    the    same 
ways    as    SNAP    I    was    shown    to    have    benefitted,    from    a 
telecommunications    interface    with    shore    based    sites.       In 
light    of    this,    no    repetition    of    the    required    interface 
initiatives    and    programs    will    be    repeated    here. 

The   major    problem    in    interfacing    SNAP    II    units    with 
SPLICE    is    that    SNAP    II    hardware    will    only    support    an 
asynchronous,    intelligent    terminal/PC    oriented    off-ship 
interface,    instead    of    the    above    interface    and    the 
synchronous    interface   described    in    the    SNAP    I    section.       The 
connection    to    a    SPLICE    host    would    have    to    be    via    dial-up 
phone    line    from    their    Zenith-150    (IBM    Compatible)    PC 
terminals,    when    not    operating    directly    off    the    SNAP    II 
computers,    through    a    terminal     emulation    package    compatible 
with    SPLICE.       This    could    be    accomplished    by    using    a 
software/ hardware    product    such    as    MicroGate    6530,    a    TANDEM 
6530    terminal    emulation    package,    that    enables    PCs    full 
access    to    all    the    features    available    of    a    TANDEM,    plus    the 
ability    to    up    or   download    files.       A    good    discussion    of    some 
alternative    ways    to    implement    SPLICE    interconnection    is 
prov  id  ed     in    [ Ref .    115] . 

The  final  area  that  will  be  addressed  is  how  SNAP  II 
tactically  supports  or  can  be  made  to  better  support  the 
proposed    SPLICE    objectives,    thereby    supporting    previously 
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presented  corporate  and  project  goals  and  strategies.   SNAP 
II  directly  supports  and/or  is  supported  by  the  following 
SPLICE  project  objectives:  12,  15,  16,  19,  21,  22,  33,  and 
35. 

There  are  several  recommendations  the  authors  have  for 
possible  enhancements  to  SPLICE/SNAP  II  that  will  enable 
them  to  provide  greater  support  or  benefit  to  the 
corporation  and  to  the  Navy  as  a  whole: 

1.  Investigate  and  test  the  software  to  support  the  SNAP 
II  user  interfaces  to  the  SPLICE  system  via  the  smart 
terminal/PCs  installed  on  the  ships  and  a  modem  using 
an  asynchronous  interface.  This  interface  would 
provide  for  both  shipboard  on-line  inquiry  and  bulk 
file  transfer  capabilities  using  software  such  as  the 
MicroGate  6530. 

2.  Investigate  the  possibility  for  using  SPLICE  to 
provide  the  gateway  to  DDN  for  shipboard  users  using 
NARDACs  as  hosts.   This  would  provide  shipboard  access 
and  system  interoperability  necessary  for  systems  such 
SDSA  and  IDAFMS. 

3.  Investigate  the  possibility  of  using  SPLICE  for 
shipboard  access  to  AUTODIN  I  via  a  DDA  interface  at 
the  NARDACs,  including  the  SNAP  II  ship  DDN  accounts/ 
electronic  mail  boxes  being  located  there.   This  would 
allow  all  SPLICE  users  and  DDN  users  the  ability  to 
send  information  electronically  to  the  ships.   Data 
such  as  COSAL  updates.  Disbursing,  Financial,  and 
Personnel  documents,  returns,  and  reports  could  then 
be  passed  to  the  shore  community  in  this  manner  on- 
line. 

This  concludes  the  discussion  of  SNAP  II.   The  NALCOMIS- 

SPLICE  interface  will  next  be  addressed. 

F.   NRMM  APPLICATION  INTERFACES 

The  Naval  Aviation  Logistics  Command  Management 
Information  System  (NALCOMIS)  interface  to  the  logistics 
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community    is    through    the    NALCOMIS    Repairables    Management 
Module    (NRMM).       NRMM    interfaces    with    both    SNAP    I    SUADPS    and 
shore    based    air    stations    via    UADPS-SP    or    UADPS-LEVEL    11.92 
NRMM    runs    on    the    SNAP    I    computers    as    a    real-time,    management 
information    system.       It    was    designed    to    increase    and    provide 
better    support    of    the    aviation    logistics    and    maintenance 
efforts    of    squadrons    while    they    are    shore    based    or    embarked 
on    ships. 

NRMM    will    take    both    terminal     inputs    and    magnetic    tape 
inputs.       Its   data    is    stored    on   magnetic    disks    that    can    be 
accessed    by    users    from    remote    terminals    located    on    the 
ships.       Outputs    consist    of    terminal    displays,    printed 
reports,    magnetic    tapes,    disk,    punch    cards,    and    paper    punch 
tape . 

NRMM    is   designed    to    allow    its    users    to    achieve    rapid 
retrieval    of    information    from    its    data    base    or    input    to    it. 
In    doing    so,    it    allows    users    to    monitor    all     facets    of    an 
IMA's    logistic    data:    status    of   outstanding    requisitions, 
local    rotatable    pool    assets,    support    equipment,    and    cross- 
reference    of    part    numbers    and    stock    numbers    for    degree    of 
family    i n terc hang eab i 1 i ty .       The    system    also    provides 
technical    publication    records,    tracking    of   cannibalized 
assets    for    each    airframe,    as    well    as    performing    other 
administrative    tasks. 


^2in    this   document    the    authors    will    address    only    the 
UADPS-SP    interface;    insufficient    information    concerning    the 
UADPS-Level     II    interface    was    available    to    address    it. 
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NRMM    interfaces    ashore    to    UADPS-SP,    and    afloat    to 
SUADPS,    by    using    punched    cards    and    magnetic    tapes    as    both 
input    and    output.       The    NRMM    outputs    are   mainly    requisitions 
and    follow-ups    for   material.       Its    external    logistics    inputs 
are    to    NRMM    are    requisition    status    images    and    management 
data    information    via    Master    Stock    Item    Records    (MSIR) 
updates.       Selected    MSIR    data    from    UADPS-SP    is    actually 
overlayed    on    the    NRMM    data    base.       This    is    called    Aviation 
Coordinated    Allowance    List    (AVCAL)     update.       During    this 
process,    the    NRMM    records    are    updated    to    reflect    MSIR 
material    management    information    such    as    on-hand    quantities, 
MCC,    LMC,    COG,    SMIC,    SM&R,    and    purpose    codes.       NRMM    also 
uses    the    results    of    UADPS    processing    of    the    FMSO    change 
notice    action    tapes    to    update    the    NRMM    NSN    records.    [Ref 
116] 

Since    NRMM    will    be    running    shipboard    on    SNAP    I    hardware 
it    seems    that    instead    of    using    magnetic    tapes    or    punched 
cards    as    input    and    output    to    the    Air    Stations    or    Stock 
Points    that    the    same    SNAP    I    telecommunications    interfaces 
recommended    earlier    could    also    benefit    NRMM.       Since   many    Air 
Stations    are    also    SPLICE    sites,    the    updates    from    the 
replicated    MSIR    or    UADPS-SP    status    of    requisitions    could    be 
sent    via    SPLICE    telecommunications    to    the    NRMM/SNAP    I 
hardware    site,    via    the    file    upload /download    capabilites 
described    in    the    SNAP    I    section    above,    vice    hand    carried    in 
card /tape    fo  rmat . 
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In  that  NRMM  runs  on  the  SNAP  I  hardware,  the  same 
SPLICE  objectives  that  apply  for  SNAP  I  also  apply  for  NRMM. 
The  recommendations  that  were  made  for  SNAP  I,  hold  equally 
well.   Further  since  NRMM  is  used  on  SNAP  I  hardware  located 
at  the  Naval  Air  Stations  while  the  squadrons  are  not 
deployed,  the  argument  for  development  of  a  bisynchronous 
link  for  intercommunications  to  the  SPLICE  system  at  the  Air 
Stations  or  the  nearest  SPLICE  site  makes  even  more  sense 
then  the  planned  use  of  magnetic  tape  or  cards  for 
information  transfer. 

This  concludes  the  discussion  of  NRMM,  the  final  area  of 
discussion  in  this  chapter  on  shipboard  telecommunications 
interoper ab  il i  ty . 
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XI.   SUMMARY  AND  CONCLUSIONS 

A.   SUMMARY 

Until  very  recently,  the  SPLICE  project  has  had  a 
limited  effect  on  the  NAVSUP  and  logistics  operational 
communities.   As  has  been  seen  in  this  document,  since  the 
signing  of  the  SPLICE  contract  in  fiscal  year  (FY)  1984  the 
seeds  to  dramatically  increase  that  effect  in  both  range  and 
depth  have  been  laid. 

The  SPLICE  project  began  dynamically  in  the  late  1970's, 
with  plans  for  rapid  development  and  deployment  of  both 
environmental  and  application  software,  based  upon  PE 
systems.   Its  purpose:  to  resolve  Burroughs  capacity, 
telecommunications,  and  architectural  deficiencies,  while 
standardizing  stock  point  minicomputers  and  adding 
interactive  processing  capabilities.   When  limitations  in 
this  plan  forced  NAVSUP  to  competitively  solicit  SPLICE 
hardware  and  system  software,  the  project  all  but 
disappeared  from  notice  for  several  years.   The  capacity 
problems  had  to  be  addressed  with  additional  Burroughs  and 
PE  hardware,  while  SPLICE  targeted  applications  migrated  to 
ADP  systems  where  immediate  capacity  was  forthcoming. 

During  this  time,  however,  SPLICE  planning  was  not 
dormant.   As  requirements  and  needs  changed  within  the  stock 
point  system,  SPLICE  changed  with  them.   Although  this 
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caused  great  fluctuations  in  detailed  environmental  designs, 
SPLICE  plans  were  consistently  based  upon  perceived  and 
anticipated  future  needs  of  the  stock  points.   The  SPLICE 
networking  and  interoperability  plans  support  this  view. 

Once  the  SPLICE  contract  was  within  NAVSUP's  immediate 
grasp  in  FY  1984,  the  project  again  came  forward  into  the 
lime  light,  with  large  amounts  of  capacity  and  Burroughs 
saturation  relief  potentially  available,  but  without 
applications  to  take  advantage  of  it.   At  this  point, 
applications  were  found  and  implemented  for  immediate 
capacity  payback  (i.e.,  TLOD,  FILE  REPS  for  Inquiry, 
TRANSRECON  Offload,  and  Burroughs  Pr e- proces sor ) .   In  many 
cases,  the  full  potential  for  these  applications  was 
downplayed  in  order  "to  get  something  out  there."   Only  now 
are  limited  efforts  underway  to  exploit  SPLICE  processing 
capabil ities. 

SPLICE  planning  has  mostly  been  geared  toward  required 
project  Life  Cycle  Management  approvals.   When  NAVSUP 
changed  direction  and  undertook  a  corporate  planning  view, 
SPLICE  plans  were  found  outdated,  still  geared  toward 
immediate  stock  point  environmental  needs,  and  looking 
toward  isolated  stock  point  implementations  (i.e.,  APADE, 
SPLICE  ABE,  STATLOC,  NAVADS,  FMSO  IDA,  and  UCEPS).   There 
has  been  insufficient  time  for  the  project  to  analyze  how  it 
and  these  efforts  could  be  integrated  to  provide  maximum 
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benefit  to  the  corporation  at  large,  with  the  notable 
exception  of  SPLICENet. 

This  work  has  taken  the  "corporate  view"  in  assessing 
the  SPLICE  project's  goals,  strategies,  and  objectives  in 
order  to  propose  a  revised  set  of  each  for  consideration  and 
possible  adoption  (i.e..  Chapter  III).   These  revised 
planning  tools  were  then  applied  to: 

1.  existing  and  potential  SPLICE  applications,  both 
centrally  designed  (i.e..  Chapter  IV]  and  local 
designed  (i.e..  Chapter  V); 

2.  and  existing  and  potential  interfaces,  both  shorebased 
(i.e.,  Chapters  V  and  VII)  and  shipboard  (i.e.. 
Chapter  VIII) . 

As  a  result  of  the  review  of  these  tactical  plans,  numerous 

recommendations  have  been  made  throughout  Chapters  III 

through  VIII  on  potential  ways  to  increase  corporate  support 

and  to  achieve  corporate  objectives  through  changes  in 

specific  SPLICE  or  application  initiatives. 


B.   CONCLUSIONS 

The  SPLICE  project  can  have  a  critical  role  to  play 
within  NAVSUP  and  the  stock  point  community.   The  magnitude 
of  this  role  will  be  determined  by  the  degree  that  the 
project  can  integrate  itself  into  the  framework  of  NAVSUP 
corporate  plans  and  objectives,  while  assuming  a  leadership 
role  in  defining  the  interim  stock  point  information 
arc  hi  tec  tur e . 

Between  SPLICE  and  the  Burroughs  B4900  CPU  replacement 
initiatives,  significant  capacity  has  been  brought  to  the 
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doorway  of  the  stock  points;  sufficient  capacity,  in  the 
authors'  opinion,  to  sustain  the  stock  points  through  the 
decade.   The  B4900  capacity  can  be  implemented  immediately; 
the  SPLICE  capacity  only  through  new  download  applications, 
the  integration  of  existing  TANDEM  based  efforts,  and 
implementation  of  new  additional  applications,  as  described 
in  this  document.   It  appears  that  the  SPLICE  capacity  will 
be  largely  unused,  however,  due  to  current  plans  to  forgo 
new  SPLICE  efforts  in  favor  of  the  transition  of  current 
Burroughs  processing  applications  on  the  soon  to  be  procured 
SPAR  hardware. 

If  the  SPLICE  project,  together  with  the  NAVSUP  and  FMSO 
stock  point  functional  codes,  were  to  boldly  take  the 
initiative  to  implement  applications  on  the  already  known 
and  available  SPLICE  systems,  the  need  to  undertake  SPAR 
transition  would  not  exist.    Rather  than  go  through  the 
labors  of  transitioning  UADPS-SP  in  its  current  form  and 
implementing  it  at  a  few  NAVSUP  sites  during  the  remainder 
of  this  decade,  the  authors  have  concluded  that  B4900  and 
SPLICE  UADPS-SP  application  "modernization"  initiatives 
should  be  undertaken.   Permitting  SPLICE  and  the  B4900s  to 
shoulder  the  burden  of  capacity  through  this  decade  would 
relieve  SPAR  from  rushing  into  an  unknown,  costly,  and 
potentially  risky  transition  of  applications  to  new  hardware 
and  software  that  would  do  little  more  than  they  do  today. 
If  only  a  portion  of  the  SPAR  transition  effort  were 
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expended    on    SPLICE    initiatives,    real     processing    improvements 
would    be    provided    to    the    stock    points    in    the    short    term. 
This    would    also    permit    SPAR    to    concentrate    on    UADPS-SP 
modernization:    the    long    term    need    of    and    goal     for    the    stock 
po  i  n  ts  . 
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APPENDIX  A 


NAVSUP  STRATEGIC  INFORMATION  SYSTEM  PLAN  OPPORTUNITIES 

I  INVENTORY  MANAGEMENT 

*  1.       Improve    visibility    of    Navy-owned    assets    to    promote 
greater    logistics    support    effectiveness. 

2.  Enhance    weapons    system    management    capabilities. 

3.  Improve    performance   measures    for   determining    weapons 
systems    support    effectiveness. 

4.  Improve    fleet    support    by    use    of    item    essentiality    codes 
and    more    accurate    shortage    cost    estimates    for    wholesale 

r epl en  i  shmen t . 

5.  Improve  retail  aviation  support  through  use  of  a  new 
AVCAL  model  (RIMAIR)  . 

6.  Improve  capability  to  make  procure  versus  repair 
decisions  for  intermediate  and  depot  level  repairables. 

7.  Improve  supply  effectiveness  with  capability  to  detect 
and  eliminate  supply  pipeline  constrictions  in  a  real  time 
env  ironmen  t . 

8.  Improve  the  capability  to  determine  mult i -echelon 
stocking  decisions  at  wholesale,  intermediate  and  consumer 
levels,  and  by  weapons  system. 

9.  Satisfy  a  SMPG  requirement  by  providing  a  capability  to 
distinguish  sources  of  demand,  i.e.,  customer  in  terms  of 
UIC,  service,  country,  etc. 

*  10.   Improve  capability  to  provide  ICP  and  stock  point 
managers  with  sensitivity  and  trade  off  analysis  ("what  if" 
models)  results  for  mater i al / fund s/ ef fee ti v en  ess  questions. 

11.  Improve  operational  readiness  for  new  systems  by 
implementing  the  wholesale  provisioning  model. 

12.  Improve  effectiveness  of  SPCC  load  lists  by  adopting 
and  implementing  the  availability  model. 

*  13.   Satisfy  OSD  requirements  (RIMSTOP)  to  implement  a 
three- ec hel on  supply  system. 
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14.   Improve  techniques  for  measuring  supply  system 
performance  and  customer  satisfaction. 


II  DATA  MANAGEMENT 

*  15.   Improve  inventory  accuracy,  data  quality  and  control 
through  improved  application  design  and  operational 
procedures  at  ICPs  and  Stock  Points. 

*  16.   Improve  the  quality  and  accessibility  of  data  by 
establishing  a  program  to  manage  data  as  a  corporate 
resource. 

17.   Improve  systems  effectiveness  through  the  participation 
in  Navy  wide  functional  data  architectural  reviews  to 
standardize  systems,  promote  data  sharing  and  streamline 
information  flow. 

*  18.   Reduce  data  redundancy  and  promote  data  sharing, 
accessibility  and  accuracy  through  the  incorporation  of 
common  data  elements  in  an  integrated  data  base  environment 
that  serves  ICPs,  SPs,  HSCs,  and  other  shore  and  afloat 

c  ustomer s . 

*  19.   Facilitate  interservice  sharing  and  exchange  of  data 
to  improve  common  logistical  support. 

*  20.   Provide  adequate  policy  for  protection  of  ADP 
resources  through  an  effective  ADP  Security  Program. 

21.   Promote  integrity  and  efficiency  by  providing  internal 
controls  in  application  programs  and  environmental  software. 


Ill  SYSTEM  INTEGRATION 

*  22.       Improve    the    use    of    hardware    and    software    systems 
through    the    definition    of    the    integration    requirements    for 
on-going    and    planned    initiatives    such    as    office    automation, 
telecommunications,    SPLICE,    Stock    Point    Replacement    and    ICP 
Resol i citation. 

*  23.       Promote    competition    in    future    information    system 
resource    acquisitions    by    developing    portable    and    machine 


independent    application    programs. 


*    24.       Improve    local    telecommunications    capabilities    at 
NAVSUP    activities    and    Navy    stock    points    by    installing    local 
area    networks. 
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*  25.       Determine    the    requirements    for    automated    exchange    of 
information    between    and    among    field    activities    and 
headquarters    via    a    command    wide    communications    network. 

*  26.       Improve    the    use    of   micro-computers    and    their    off- 
the-shelf    software,    in    the    management    and    exchange    of 
information,    within    and    among    NAVSUP    components. 


IV    SYSTEM    MODERNIZATION 

*  27.       Improve    reliability,    timeliness    and    quality    of   data 
by    reducing    the    use    of    PCAM    equipment    and    hard    copy    outputs 
in    financial,    procurement    and    supply    systems    through    the    use 
of   computer    output    microform    and    video    display    terminals. 

*  28.       Improve    user    capabilites    and    data    processing 
efficiency    and    reliability    through    the    replacement    of 
obsolete,    worn    out    ADPE. 

*  29.       Improve   mobilization    and    workload    expansion 
capabilities    at    ICPs    and    SPs. 

*  30.       Eliminate    Navy-unique    systems    software    through    the 
use    of   vendor    off-the-shelf    environmental     software. 

*  31.       Reduce    paperwork    and    improve    productivity    and 
administrative   management    by    developing    office    automation 
systems    to    provide    tools    such    as    electronic    mail,    text 
editing,    electronic    files,    electronic    calendars,    and 
graphics    within    NAVSUP    HQ    and    its    field    activities. 

*  32.       Improve    productivity    through    automation    of  manual 
proc  esses . 

33.  Improve   management    and    control    of    conventional 
ammunition    inventories    through    the    redesign    of    CAIMS. 

34.  Improve    information    systems    support    services    at    the 
stock    point    and    ICP    data    processing    installations    by 
upgrading    and    expanding    hardware    configurations    and 
facilities,     including    un i n terr uptabl e    power,    air 
conditioning    and    fire    protection. 

35.  Reduce    the    complexity    and    length    of    the    logistics 
information    systems    acquisition    process. 

36.  To    increase    user    effectiveness    and    productivity    and 
improve    the    use    of    Navy    assets    by    providing    better    systems 
and    streamlined    business   methods. 
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*  37.       Provide    for    a    less    complex,    more    flexible    and 
reliable    hardware/ software    environment    through    contractual 
vehicles    which    facilitate    technological     refreshment    and    a 
long-term    single    vendor    relationship. 

*  38.       Improve    long    haul    communication    user    access    to    ICP 
and    stock    point   data    through    the    use    of   the    Defense    Data 
Network . 

*  39.       Improve   management   decision    capability    by    enabling 
managers    to    easily    access    and    manipulate   data    through    use    of 
automated    tool s . 

*  40.       Improve    logistics   management    by    providing    easy    access 
to    configuration    and    weapons    support   data. 


V    QUALITY    PERSONNEL 

41.  Improve    productivity    and    effectiveness    by    elevating    the 
information    technology    skill    level    of    information    systems 
development    and    user    personnel     through    formal     training 
programs . 

42.  Improve    personnel    posture    through    the    development    and 
implementation    of    a    personnel     planning    program    which    would 
include    training,    mobility,    work    environment,    retention, 
staffing,    grade    structure,    recruitment,    etc. 

43.  Establish    a    cadre    of    functional     personnel    to    improve 
user    effectiveness    through    increased    emphasis    on    functional 
work    requirements    and    deficiency    statements. 


VI    RESOURCE    MANAGEMENT 

44.  Improve  the  execution  of  04  business  functions  through 
aggressive  implementation  of  NAVSUPNOTE  5400  of  20  Nov  84  ( 
04    Reorganization). 

*  45.       Improve   management    and    control    of    local    unique 
application    programs    as    by-products    of    the    ICP 

Resol icitation/UADPS-SP    Replacement. 

46.       Improve    SUP    04    consolidated    budget    information. 

*  47.       Improve    the    way    basic    business    functions    are 
performed    at    stock    points. 

48.  Improve  the  way  basic  business  functions  are  performed 
at    ICPs. 
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49.  Focus  resources  and  improve  effectiveness  of  FMSO 
products  and  performance. 

50.  Improve  effectiveness,  quality,  timeliness  and 
auditability  of  responses  to  external  reviews,  audits  and 
inquiries  from  activities  such  as  Congress,  GAO,  GSA  and  DOD 
and  Navy  organizations. 

51.  Obtain  timely  GAO  certification  of  financial  accounting 
systems . 

52.  Improve  the  use  of  hardware  and  software  resources  by 
establishing  configuration  management  and  capacity 
management  programs. 

*  53.   Insure  continuous  information  systems  services 
through  improved  contingency  capabilities. 

54.  Improve  the  ability  to  acquire  necessary  resources  in 
the  budget  process  as  a  result  of  better  documented 
requirements  through  the  IRM  program. 

55.  Strengthen  NAVSUP's  IRM  resource  acquisition  and  budget 
process  through  the  application  of  SECNAV  LCM  procedures. 

56.  Establish  a  Problem /Opportunity  Hopper  to  provide  early 
visibility  and  control  of  potential  problems  and  targets  of 
opportun  i  ty . 

57.  Establish  a  formalized  "Lessons  Learned"  process  to 
minimize  repetition  of  past  mistakes. 

58.  Increase  the  use  of  statistical  techniques  to  measure 
and  improve  operations. 

59.  Institutionalize  the  strategic  and  tactical  planning 
process . 

60.  Fulfill  the  CNO  (OP  945)  IRM  planning  requirements 
through  the  SUP  04  strategic  and  tactical  planning  process. 

61.  More  effectively  respond  to  Command  Goals  and 
Objectives  through  the  SUP  04  strategic  and  tactical 
pi ann  i  ng  proc  ess . 


VII  TECHNOLOGY  EXPLOITATION 

*  62.   Provide  improved  information  systems  technology 
throughout  NAVSUP. 
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*    63.       Exploit    the    use    of    information    systems    technology    in 
the    solution    of    logistics   management    problems. 
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APPENDIX  B 


NAVSUP  STRATEGIC  INFORMATION  SYSTEMS  PLAN  ASSUMPTIONS 


I.  INVENTORY  MANAGEMENT 

*  1.   The  ICPs  and  SPs  will  continue  to  provide  weapons 
systems  logistics  support  for  the  Navy. 

*  2.   UADPS-SP,  UICP,  and  Level  II  will  continue  as  NAVSUP's 
standard  baseline  supply  and  financial  management  systems. 

*  3.   NAVSUP  will  continue  to  be  a  sponsor  for  uniform 
standard  supply  and  financial  information  systems  for  use  by 
Navy  stock  points  external  to  the  NAVSUP  Command. 

4.  Integration  of  wholesale  material  management  across  DOD 
will  increase  and  Navy  ICPs  will  serve  a  broad  range  of  DOD 
and  foreign  government  customers. 

5.  The  number  of  wholesale  line  items  managed  by  Navy  ICPs 
will  decrease  slightly,  but  emphasis  on  repairables  will 
make  item  management  more  complex. 

6.  SMPG  and  other  DOD  initiatives  will  require  development, 
analysis,  and  review  of  MRD  models  and  procedures  at  an 
increased  level  of  effort  and  complexity. 

*  7.   The  Command  emphasis  on  economic  analysis  and 
operations  analysis  will  continue  at  the  current  levels. 

*  8.   The  measurement  of  readiness  and  its  cost  by  weapons 
system  will  receive  increased  emphasis. 

*  9.  There  will  be  increased  pressure  to  use  mult i -echelon 
i  nv  en  to  ry  mod  el s  . 

*  10.  There  will  be  increased  pressure  to  achieve  complete 
visibility  of  all  inventory  assets. 


II.  DATA  MANAGEMENT 

*    11.       NAVSUP    will    recognize    information    as    a    corporate 
resource    and    implement    in    Information    Resources    Management 
( I  RM)    Program . 
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*  12.       The    requirement    to    share    common    data    among    DOD 
components,    other    government    agencies    and    contractors    will 
grow    in    emphasis    and    number    of    applications. 

*  13.       Emphasis    on    ADP    Security    will     increase. 

*  14.       Off-the-shelf    DBMSs    and    automated    data    dictionaries 
will    be    used    in    all    major    systems. 


III.     SYSTEM    INTEGRATION 

*  15.         The    hardware    and    software    technology    of    SPLICE,    ICP 
Resolicitation,    Stock    Point    ADP    Replacement    and    office 
automation    will    be    integrated. 

*  16.       The    Defense    Data    Network    will    be    the    basic    long    haul 
communications    network    of    the    Navy. 

*  17.       NAVSUP    04    will    place    increased    emphasis    on    the 
integration    of    afloat    and    ashore   management    information 
systems. 

IV.     SYSTEM    MODERNIZATION 

*  18.      Use    of   office    automation    and    PCs    will    expand 
significantly    within    NAVSUP    headquarters    and    the    field 
activities. 

*  19.       The    use    of   off-the-shelf   vendor    environmental 
software    will    minimize    the    need    for    Navy-unique 
environmental     software. 

*  20.       The    single   vendor    concept    will    continue    as    the 
preferred    procurement    strategy    for    total     information    systems 
support . 

*  21.       High    level    programming    languages    will     increase    in    use 
for    ad    hoc    reports,    queries,    and    application    programs. 


V.    QUALITY    PERSONNEL 

*  22.       Additional    training    will    be    required    to   meet    the 
needs   of   the    new   technology. 

*  23.       Information    centers    will    assist    and    train    end    users 
in    the    new    information    systems    tools    and    techniques. 

*  24.       New    technology    will    continue    to    generate    a 
requirement    for    specialized    information    systems    skills. 
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*  25.   It  will  be  increasingly  difficult  to  recruit  and 
retain  employees  because  of  more  attractive  salaries  and 
benefits  within  the  private  sector. 


VI.  RESOURCE  MANAGEMENT 

*  25.   The  internal  organization  will  be  modified  as 
required  to  meet  changing  requirements. 

*  27.   The  SUP  04  Strategic  and  Tactical  Information  Systems 
Plans  will  be  the  blue  prints  for  guiding,  shaping,  and 
directing  SUP  04's  near  and  long  term  efforts. 

*  28.   NAVSUP  will  continue  to  staff,  manage,  and  operate 
its  own  information  processing  facilities. 

*  29.   A  network  control  center  for  management  and 
administration  of  NAVSUP's  telecommunications  network  will 
be  established. 

*  30.  NAVCOMPTSSA  will  be  the  CDA  for  payroll,  leave,  and 
IDA-SP  applications. 

*  31.   Laws  and  policies  such  as  the  Paperwork  Reduction 
Act,  the  Brooks  Act,  Warner  Amendment,  the  Commercial 
Activities  Program,  and  FARs  will  continue  to  influence  and 
complicate  information  systems  management. 

*  32.  Emphasis  on  fraud,  waste,  and  abuse  and  the  Federal 
Managers  Financial  Integrity  Act  of  1982  will  continue  and 
oversight  will  intensify. 

*  33.   Telecommunications  tariff  rates  will  increase  at 
about  20  percent  per  year  over  the  next  3  years. 

*  34.   Efforts  will  be  made  to  replace  current  workload 
measurement  techniques  with  engineered  standards  and 
statistical  methods. 

*  35.   There  will  be  continuing  pressure  to  resource 
information  systems  operations  outside  the  NAVSUP  claimancy. 

*  36.   Business  workload  at  SPs  and  ICPs  will  continue  to 
increase. 

*  37.   Use  of  contractors  to  provide  technical  support  will 
i  ncrea  se . 

*  38.   Decision  support  systems  will  be  increasingly 
automated . 
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*  39.      Productivity    increases    will    be    used    to   meet    resource 
short  f al 1 s . 

*  40.       There    will    be    increased    emphasis    on    policies    and 
standards    to    effectively    exploit    technology    and    implement 
IRM    requirements. 

*  41.       There    will    be    an    increased    demand    for    establishing 
and    maintaining    controls    to   more    effectively    manage    SUP    04 
functions. 


VII.    TECHNOLOGY    EXPLOITATION 

*  42.  The  capabilities  of  office  automation  systems  and  PCs 
will  continue  to  increase  with  corresponding  improvements  in 
the    price/performance    ratio. 

*  43.  Use  of  off-the-shelf  application  packages  will  be  the 
standard    practice    for    PCs    and    Office    Automation    Systems. 

*  44.       Computer    price/performance    ratio    will    continue    to 
im  prove . 

*  45.      New   application   development    productivity    tools    will 
reduce    the    time    required    to    develop    information    systems. 
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APPENDIX  C 


NAVSUP  STRATEGIC  INFORMATION  SYSTEMS  PLAN  STRATEGIES 


I.  INVENTORY  MANAGEMENT 

1.  NAVSUP  04  will  improve  fleet  readiness  through  inventory 
management  by  weapons  system  and  by  achieving  the  mean 
supply  response  time  to  meet  readiness  goals. 

2.  Wholesale  material  requirements  determination  emphasis 
will  be  on  repairables  and  high  essentiality  consumables. 

3.  Navy  will  provision  for  all  echelons  of  support. 

*  4.   Navy  supply  support  will  be  provided  through  consumer, 
intermediate  and  wholesale  echelons,  with  the  long  term 
intention  that  calculation  of  inventory  levels  for  these 
echelons  will  be  integrated  to  the  maximum  degree  feasible. 


II.  DATA  MANAGEMENT 


*  5.   NAVSUP 
resource. 


will  manage  information  as  a  corporate 


*  6.   The  Data  Administration  program  will  be  implemented  in 
NAVSUP  to  promote  coordinated  and  integrated  policies, 
programs,  and  procedures  to  efficiently  and  effectively 
manage  and  control  corporate  data  and  supporting  resources. 

*  7.   Security  procedures  based  on  economic  risk  analyses 
will  be  used  to  protect  information  systems  from  erroneous 
denial  of  services,  or  unauthorized  accidental/ intentional 
destruction,  modification,  or  disclosure. 

*  8.  Information  systems  will  be  designed  to  electronically 
collect,  validate  and  process  data  as  close  to  the  source  as 
po  ssi  bl e  . 


III.  SYSTEM  INTEGRATION 

*  9.   NAVSUP  04  will  emphasize  the  integration  of  logistics, 
business,  and  administrative  information  systems,  through 
standard  coding  structures  and  common  data  bases. 
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*  10.   NAVSUP  04  will  establish  a  comprehensive  long 
distance  and  local  telecommunications  network  that  provides 
all  authorized  users,  ashore  and  afloat,  ready  access  to 
logistics  information  in  NAVSUP  data  bases. 


IV.  SYSTEM  MODERNIZATION 

*  11.   NAVSUP  04  will  improve  the  effectiveness  and 
usefulness  of  its  information  systems  by  purifying  data 
bases,  acquiring  efficient  hardware,  software,  facilities 
and  developing  systems  which  meet  customer  needs. 

12.   Emphasis  will  be  placed  on  functional  requirements  vice 
technical  specifications  for  hardware  and  software 
proc  ur ements . 

*  13.   Portable  and  machine  independent  application  programs 
will  be  developed  to  promote  competition  in  future 
information  systems  resource  acquisitions. 

*  14.   Proven,  commercially  available  hardware  and  software 
products  will  be  used. 


V.  QUALITY  PERSONNEL 

15.  NAVSUP  04's  employee  training  and  development  programs 
will  emphasize  improved  job  performance. 

16.  NAVSUP  04  will  pursue  a  comprehensive  employee  quality 
of  life  program  that  enhances  job  satisfaction. 

17.  NAVSUP  04  will  pursue  a  military  and  civilian  manager 
mix  that  achieves  an  effective  balance  between  continuity 
and  innovation  in  key  management  positions. 

18.  SUP  04  will  emphasize  employee  productivity, 
accountability,  performance  quality  and  related  incentive 
systems . 


VI.  RESOURCE  MANAGEMENT 

*  19.   All  SUP  04  information  systems  actions  will  be 
initially  justified  by  economic  analyses  and  subsequently 
audited  for  achievement  of  analysis  objectives. 

*  20.   NAVSUP  04  will  optimize  the  use  of  FMSO  resources  for 
major  standard  information  systems  with  emphasis  on  new 
systems  d  ev  el opment . 
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*  21.   All  SUP  04  information  systems  actions  will  be 
documented  and  managed  through  the  SUP  04  Strategic  and 
Tactical  Information  Systems  Plan  and  will  support  the 
NAVSUP  Corporate  Plan  and  the  Navy  ISSP. 

*  22.   SUP  04  will  apply  Life  Cycle  Management  procedures  as 
the  standard  methodology  for  all  Information  Systems 

pro j  ec  t s  . 

*  23.       NAVSUP    04    will     improve    the    effectiveness    of    its 
hardware,    software,    and    facilities    through    the 
implementation    of    a    configuration    and    capacity    management 
prog  ram . 

*  24.       NAVSUP    04    will    manage    and    control     the    cost    of    its 
data    processing    services    through    the    initiation    of   customer 
charge-back    systems. 

25.       NAVSUP    04    will     implement    the    organization    in    accordance 
with    the   design    concept. 

VII.    TECHNOLOGY    EXPLOITATION 

*  26.       NAVSUP    04    will    be    the    advocate    for    state-of-the-art 
technology    in    information    system    initiatives. 

*  27.       Technology    refreshment    will    be    built    into    all    long 
term    acquisition    and    budget    strategies. 
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APPENDIX  D 


lAVSUP  STRATEGIC  INFORMATION  SYSTEMS  PLAN  OBJECTIVES 


I  INVENTORY  MANAGEMENT 


OBJECTIVE 


STRATEGY 


(FY/Q) 
TARGET 
DATE 


1.   Implement  an  improved 
AVCAL  model  (RIMAIR)  at  ASO. 


86/3 


2.   Implement  item  essentiality 
codes  and  more  accurate  shortage 
cost  estimates  for  ICP  wholesale 
repl en  i  shment . 


1,2 


86/2 


*    3.       Implement    sensitivity    and 
trade-off    analysis    ("What    If") 
capabilities    to    answer    material/ 
funds/effectiveness    questions    by 
ICP    i  tern   manag  er . 


1.2 


86/2 


4.       Implement    a    uniform    and 
improved    wholesale    provisioning 
model    at    ICPs. 


3,2 


87/4 


*  5.  Complete  the  implementation 
of  the  RIMSTOP  capability  at  Navy 
ac ti V  i ti  es  . 


91/4 


6.   Implement  a  sparing  to 
availability  model  with  item 
essentiality  coding  to  develop 
a  shipboard  and  aviation 
provisioning  capability. 


3,2 


88/4 
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OBJECTIVE 


STRATEGY 


(FY/Q) 
TARGET 
DATE 


*    7.       Identify    the    actions 
required    to    accelerate    the 
implementation    of    the    multi-echelon 
requirements    determination    model. 
(SUP    1) 


86/4 


8.   Implement  a  mult  i -echelon 
requirements  determination  model 
(wholesale,  intermediate,  and 
consumer)  for  ICP  replenishment 
by  weapons  systems.   (SUP  18. d.) 


95/4 


9.   Define  and  implement  a  system 
to  measure  supply  and  operational 
availability  performance  objectives 
by  weapons  system.  (SUP  15) 


89/4 


10.   Define  those  measurements,  levels   1 
of  application  and  systems  required  to 
determine  the  effectiveness  of  the 
suppl y  system .   ( SUP  23) 


86/2 


*  11.   Validate  rules  and  integrate 
models  for  procurement  and  repair 
requirements  determination.   (SUP  17) 


2,4 


91/2 


*    12.       Develop    and    implement    procedures    4 

to   minimize    repetitive    buys    of 

nonstandard    and    Navy   managed    items.    (SUP    32) 


88/4 


13.       Support    the   development 

of    uniform    weapons    system    and 

related    essentiality    coding.       (SUP    16) 


90/4 


II  DATA  MANAGEMENT 


*  14.   Establish  an  operational 
IRM  program.   (SUP  107) 


5,9,25 


86/4 
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OBJECTIVE 


STRATEGY 


(FY/Q) 
TARGET 
DATE 


*  15.   Establish  operational  Data 
Administration  and  Data  Base 
Administration  Programs.   (SUP  108) 


86/2 


*  16.   Write  NAVSUP's  instruction 

on  contingency  planning  incorporating 

OPNAVINST  5239.1 


86/3 


*  17.   Rewrite  the  ADP  security 
instruction,  NAVSUPINST  5510. 6A 


86/2 


18.   Develop  ICP  mobilization/ 
contingency  plan. 


7,11 


87/1 


III  SYSTEM  INTEGRATION 


*  19.   Define  and  overall 
information  architecture  that 
supports  the  NAVSUP  business 
functions.   (SUP  110) 


9,6 


86/3 


*  20.   Develop  the  data 
architecture  that  supports  the 


ov  eral 1  in  formati  o  n 
(SUP  112) 


architecture. 


9,5 


87/1 


*    21.       Based    on    the    NAVSUP    information 
architecture,    develop    and    overall 
technical    plan,    including    telecom- 
munications,   office    automation,    and 
security    considerations,    that    exploits 
the    technology    available    through 
existing    and    planned    procurements    such 
as    SPLICE,    ICP,    and    SPAR.       (SUP    113) 


9,7,11 
23,12 


87/3 
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OBJECTIVE 


STRATEGY 


(FY/Q) 
TARGET 
DATE 


*  22.   Develop  a  policy  which  allows 
for  interim  but  standard  office 
automation  systems  at  NAVSUP  field 
activities,  exclusive  of  ICPs. 


85/4 


23.   Install  an  integrated  office 
automation  system  in  NAVSUP  HQ. 


9,8,11     88/2 


*  24.   Install  a  standard  office 
automation  architecture  at  NAVSUP 
field  activities  exclusive  of  ICPs 
and  NSCs. 


9,8,11     88/2 


25.   Install  a  local  area  network 
in  NAVSUP  HQ. 


9,8,11     88/2 


*  26.   Install  a  logi sties 
telecommunications  network  using 
the  Defense  Data  Network  (DON) 
as  the  backbone.   (SUP  81) 


10,14 


89/4 


27.       Develop    and    implement    a    network 
administration    strategy. 


10 


87/1 


*    28.      Develop    a    plan    to    improve 
ship    to    shore    communication    of 
logistics    information. 


10 


88/1 


29.   Install  ICP  secure  network. 

*  30.   Complete  installation  of 
SPLICE  initial  hardware  at  7  sites 


10,14,24   87/2 
10        86/4 


*  31.   Complete  installation  of 
SPLICE  upgrade  configurations  at 
8  sites  to  support  application 
impl ementation. 


11 


86/4 
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OBJECTIVE 


STRATEGY 


(FY/Q) 
TARGET 
DATE 


*  32.   Complete  transfer  of 
communications  devices  from 
Burroughs  communication  processors 
to  SPLICE  communications  subsystems 
at  NAVSUP  Stock  Points. 


10,23 


86/4 


*    33.       Complete   design,    development 
and    testing    of    SPLICE    Phase    II 


(MAPS    support) 
7    sites. 


and    prototype    at 


10 


86/4 


*  34.   Replace  OLA  PE  7/32s  with 
SPLICE  hardware  at  stock  points. 


11 


87/1 


*  35.   Complete  development  of  TCP/IP 
protocol  for  DON,  and  prototype  at 
one  si  te . 


10 


86/2 


*    36.       Define    and    execute    the 
integration    requirements    for 
on-going    and    planned    initiatives 
such    as    SPLICE,    SPAR,    ICP 
Resolicitation    and    office    automation 
through    formal    working    group. 
(SUP    12    and    102) 


89/1 


IV  SYSTEM  MODERNIZATION 


*  37.   Implement  the  DOD  Inter- 
changeab  il i  ty  and 
Substitutability  System. 


11,8,9 
19,20 


87/1 


*  38.  Develop  a  proposal  for 
establishing  and  operating  an 
Information    Center    at    NAVSUP    HQ 


11,8,9 


86/4 


39.       Implement    new    weapons    systems 
download    requirements. 


11,8,9 
19,20 


89/1 


259 


OBJECTIVE 


STRATEGY 


(FY/Q) 
TARGET 
DATE 


40.   Implement  Centralized 
Accounting  and  Billing  (CAB) 
processing  procedures  at  the 
Naval  Avionics  Center  and  the 
Level  II  Naval  Air  Stations. 


11,8,9 
19,20 


86/4 


41.       Implement    MILSCAP    contract 
abstracting    procedures    at    the    ICPs 


11.8,9 
19,20 


85/3 


*    42.       Complete    installation    of 
Integrated    Disbursing    and 
Accounting    applications    on 
SPLICE    hardware. 


11,8,9 
19,20 


88/2 


*    43.      Prepare    for    implementation    of 
IDA/FMS    and    NAVCIPS    on    NAVCOMPT 
provided    ADPE    and    application 
so  f twar e . 


11,8,9 
19,20 


89/4 


44.       Revise    automated    NSF    procedures  11,8,9 

in    accordance    with    OSD    direction.  19,20 


88/4 


45.   Automate  DLR  GFM/GFE  at 
contractor  plants. 


11,8,9 
19,20 


89/4 


46.       Modify    financial    and 
supply    applications    (UADPS    and 
UICP)    to    implement    end    use    funding 
of    Aviation    Consolidated    Allowance 
Lists. 


11,8,9 
19,20 


86/3 


47.      Develop    and    implement 
Coordinated    Shipboard    Allowance 
List    (COSAL)    download    capability 


11,8,9 
19,20 


85/4 


48 


Install  ICP  hardware. 


11,14,24   89/2 
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OBJECTIVE 


(FY/Q) 
TARGET 
STRATEGY  DATE 


49.  Complete    ICP    Transition. 

50.  Install     ICP    Office    Automation 
Sy  stems. 


11,20  87/2 

11,9,24         86/4 


51.       Implement    "Lights    Out"    Data 
Center    Plan    at    ICPs. 


11,23,24      88/3 


52.       Ensure    compatibility    of 
inventory    levels   models    and 
information    systems   design.       (SUP    118) 


11 


89/2 


53.  Make  a  decision  on  the  use 
of  SAGE  as  a  portability  and/or 
conv  er sion  tool  . 


13 


86/1 


*  54.   Develop  a  software  portability    13 
pi  an. 


86/4 


55.       Receive   vendor    proposals    for 
SPAR    hardware    and    systems    software. 


11,12,24      86/1 


*    56.       Complete    development    of    the 
SPAR    transition/conversion    strategy. 


13,19,20      86/1 


57.       Award    a    contract    for    SPAR 
hardware    and    system    software. 


11,12 
22,24 


87/2 


58.       Award    a    SPAR    conversion    contract.       11,12,14        87/3 


59.       Complete   modernized    UADPS-SP 
software   development    on    the    SPAR 
test   bed. 


11  ,8,13 
19,20 
21  ,22 


89/3 


60.       Complete   deployment    of 
modernized    UADPS-SP. 
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11,20,22      92/2 


OBJECTIVE 


(FY/Q) 
TARGET 
STRATEGY     DATE 


*  61.   Complete  APADE  Phase  I 
integrated  system  testing. 


11,8,13    86/1 


62.   Receive  SDP  III  approval 
for  APADE. 


11  ,19 
21,22 


86/3 


63.       Complete    APADE    installations 


11 


88/4 


64.   Complete  ICP  Resystemization. 


65.   Install  B4900s  at  NSC  Norfolk 


11,8,9 

19,20,1 

2,3,4 

11  ,14 


89/2 


85/3 


6  6.   Install  B4800s  and  B4900s 
at  selected  stock  points. 


11,14 


86/4 


67.   Eliminate  B3500s  from  stock 
po  i  nts . 


11 


86/4 


*  68.   Complete  replacement  of  stock    11 
point  obsolete  peripheral  equipment. 


87/4 


*  69.   Eliminate  PCAM  equipment  at      11 
ICPs,  NSCs,  CDAs,  and  other  activities 
that  are  within  NAVSUP  control  and  from 
whom  they  receive  input.   (SUP  34) 


91/1 


70.   Install  uninterruptable  power 
supply  (including  diesel  generators) 
capability  at  the  ICPs  and  NSCs. 


11 


87/2 


71.   Complete  renovation  of  the  NSC 
data  processing  facilities. 


23 


87/4 
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OBJECTIVE 


STRATEGY 


(FY/Q) 
TARGET 
DATE 


*  72.   Incorporate  decision  support 
systems  in  SPAR  and  ICP 
Resolicitation  that  provide  the 
information  required  for  activity 
management  and  HQ  feedback.   (SUP  114) 


11 


89/3 


*  73.   Develop  and  execute  the 
methodology  to  eliminate  errors  in 
existing  stock  point  and  ICP  data 
bases  and  insure  the  quality  of  new 
input.   (SUP  106) 


11 


89/3 


74.   Transition  CAIMS 


11,14 


86/2 


75.   Resystemize  CAIMS. 


11,12,13 
14,19 


88/2 


V    QUALITY    PERSONNEL 


76.       Facilitate    SUP    04    modular 
furniture    installation    and 
physical    rel ocation . 


16 


86/1 


77.   Develop  a  SUP  04  organizational 
strategy  paper  and  presentation 
appropriate  for  use  at  all  04 
empl  oyee  1  ev  el  s . 


25 


85/4 


78.       Develop    a    position   description 
and    create    a    position    for    a    SUP    04 
administrative/management    assistant 


25 


85/4 


79.       Develop    an    integrated    SUP    04 
training    plan    which    incorporates, 
consolidates,    and    tracks    current 
and    future    training    initiatives, 
including    those    provided    through 
ICP    Resolicitation,    SPAR,    and 
SPLICE. 


15,18 


85/4 
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OBJECTIVE 


STRATEGY 


(FY/Q) 
TARGET 
DATE 


80.   Develop  Individual  Development 
Plans  for  each  employee  within 
NAVSUP  04. 


15 


86/1 


81.   Write  position  descriptions 
for  and  initiate  personnel  actions 
for  all  positions  in  the  new 
organization. 


25 


85/4 


82.   Write  mission/purpose/goals 
for  each  SUP  04  branch. 


25 


86/1 


VI  RESOURCE  MANAGEMENT 


83.   Implement  a  consolidated 
budget  focal  point  within  SUP 


04. 


19 


86/2 


84.  Establish  policy  and  procedures 
for  implementing  and  maintaining  the 
SUP    04    strategic    and    planning    process 


21 


85/4 


85.       Institutionalize    a    formal 

planning    process    which    supports 

the    requirements    of    SECNAVINST    5230.9 


19 


86/2 


86.   Publish  NAVSUP  LCM  instruction 
to  implement  SECNAVINST  5231. IB 


22 


86/1 


87.   Establish  a  policy  for  executing 
and  monitoring  the  sel f- f i nanc i ng 
program  to  ensure  the  focusing  of  CDA 
re  sources  .   (SUP  62  ) 


20 


85/4 


88.      Develop    policy    and    procedures 
for    economic    analyses    and    auditing 
requirements    for    system    development 
efforts.       (SUP    43) 


19 


86/3 
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OBJECTIVE 


STRATEGY 


(FY/Q) 
TARGET 
DATE 


89 .   Dev  el  op  and  publ i  sh 
procedures  for  documenting 
"lessons  1  ear ned" . 


21 


86/1 


*    90.       Establish    a    policy    for 
management    of    local    unique 
appl i cat  ions. 


19,22 


86/2 


91.       Determine    the    feasibility 
of    using    the   operational    availability 
equation    to   measure    the    level    of 
service    provided    by    Automated 
Information    Systems    (AIS).       (SUP    97) 


19 


86/4 


*    92.       Develop    and    implement 
an    operational     hardware    and 
environmental 
program . 


software   management 


23 


89/2 


*  93.  Develop  and  implement  an 
operational  capacity  management 
prog  ram . 


23 


89/2 


*    94.       Implement  a    charge-back 

system    to   manage  and/or    recover 

costs    from    users  of    the    ICP    and 

stock    point   data  centers    and 
networks . 


24,14 


87/1 


95.       Develop    a    policy    to    transfer 
ADPE,    telecommunications, 
environmental     software,    and 
resystemized    application    programs 
from    project    to    functional    manager 


25 


86/2 
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OBJECTIVE 


STRATEGY 


(FY/Q) 
TARGET 
DATE 


VII  TECHNOLOGY  EXPLOITATIO 


*  96.   Establish  an  emerging 
technology  program.   (SUP  70) 


25 


86/2 


*  97.   Develop  policy  and  techniques 
for  the  infusion  of  new  and  emerging 
technology  into  NAVSUP  information 
sy  stems . 


26,27 


86/2 


*    98.       Develop    and    maintain    a    technical 
reference    library    on    state-of-the-art 
technology    for    hardware,    software,    and 
system    integration    techniques. 


26 


86/3 
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ATTACHMENT  E 


CURRENT  SPLICE  STRATEGIES 


SUPPORT  STRATEGIES 

1.  Enable  implementation  of  new  UADPS-SP  projects  without 
saturation  of  the  existing  Stock  Point  system  hardware. 

2.  Provide  the  Stock  Points  with  the  interactive 
capabilities  required  by  new  projects  or  download 
"functionally  transparent"  UADPS-SP  applications. 

3.  Develop  modular  telecommunications  subsystem  independent 
of  the  current  Stock  Point  computer  systems  which  will 
simplify  the  eventual  replacement  of  the  Stock  Point 
computer  systems  at  the  end  of  their  useful  life. 

4.  Provide  bulk  file  transfer  capability  for  support  of 
sites  being  provided  Multiple  Activity  Processing  System 
(MAPS)  UADPS-SP  access  from  another  SPLICE  location. 

5.  Develop  a  SPLICE  network  wherein  a  Stock  Point, 
functioning  as  a  node  in  the  network,  will  exchange 
information  with  other  Navy  Stock  Points,  Navy  Inventory 
Control  Points  or  DLA  Stock  Points  with  the  nodes  of  the 
SPLICE  network  connected  via  DDN  or  via  commercial 
communications  facilities. 

6.  Protect  the  existing  UADPS-SP  programs  from  obsolescence 
until  modernization  by  the  Stock  Point  Replacement  Project; 
permit  background  processing  with  Stock  Point  computers 
together  with  SPLICE  interactive  and  telecommunications 
functions. 

7.  Avoid  disruption  of  Stock  Point  systems'  processing 
during  SPLICE  installation  and  implementation  phases; 
configure,  operate  SPLICE  systems  to  assure  improvement  of 
Stock  Point  processing  and  throughput. 

*  8.   Locate  the  SPLICE  hardware  at  sites  currently 
processing  Stock  Point  systems  in  order  to  assure  system 
integration,  expedite  testing  and  installation  and  establish 
standardized  nodes  within  the  SPLICE  network. 
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DESIGN    STRATEGIES 

*  9.       Acquire    standard    hardware    and    software    configurations 
for   modular    implementation    at    Stock    Point    and    remote    sites. 

10.  Establish    a    standardized    telecommunications    network. 

11.  Develop    common    interactive    telecommunications 
interface{s)    among    Stock    Points,    remote    sites,    terminal 
configurations. 

*  12.       Support    stand-alone    processing. 

*  13.       Support    front-end    processing. 

*  14.       Interface    with    various    existing    Stock    Point    hardware 
(for    example,    Burroughs,    Perk i n-Elmer ,    IBM,    Univac,    Tandem). 

15.       Absorb    maximum    communications    functions    currently 
resident    on    Stock    Point    host    systems    (to    free    host 
c  a  p  a  c  i  t  y )  . 

*  16.       Insulate    the    applications    from    terminal    and    device 
unique    characteristics,    storage   media,    interprocess    routing, 
and    network    connectivity. 

*  17.       Use   modular    hardware    and    software    that    will    allow 
expansion    and    consolidation    as    workloads    and    requirements 
change    throughout    the    system's    life. 

18.  Use    off-the-shelf    environmental    (system)     hardware    and 
software    to    support    system    availability    and    data    integrity 
so    that    only    single    and    most   multiple    component    failures 
will     not    limit    access    to    the    system    by    system    users. 

19.  Allow    non-SPLICE    computer    systems    at    sites    to 
communicate    with    each    other    without    routing    messages    through 
the    SPLICE    processors. 

20.  Develop    a    centralized    network. 

21.  Prepare    a    teleprocessing    framework    for    the    Stock    Point 
Replacement    Project. 

22.  Replace    selected    MAPS    RJE    equipment    with    SPLICE 
hard  war e/ so f tware ;    expand    current    remote    and    local 
proc  ess  i  ng    features . 

ECONOMIC    STRATEGIES 

*  23.       Acquire    systems    specifically    engineered,    configured 
to    meet    specific    Stock    Point    telecommunications    requirements 
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and    provide    enhanced    interactive    processing    features    not 
available    under    Stock    Point    systems. 

*    24.       Acquire    systems    that    can    absorb    multiple    Stock    Point 
front-end    applications    thus    eliminating    separate    terminal 


systems    for    each    project    implementation    and 
consolidating/reducing    hardware,    hardware   maintenance 
per  so  nnel    costs . 


and 


25.   Install  and  implement  SPLICE  in  a  phased  manner  to 
assure  installation  success,  provide  adequate  time  for 
testing  in  a  phased  approach,  etc. 

*  26.   Specify  and  acquire  systems  that  can  be  configured  in 
standardized  units. 

*  27.   Select  limited  numbers  of  applications  for  initial 
SPLICE  processing. 

*  28.   Locate  the  SPLICE  system  in  the  same  facilities  with 
Stock  Points  computers  to  reduce  site/facility  costs, 
operator  requirements,  transmission,  transportation,  and 

1  og  i  st ic  s  costs. 

*  29.       Configure    SPLICE    to    process    in    association    with    Stock 
Point    systems    thus    sharing    workloads,    reducing    operating 
costs ,    etc . 

30.       Reduce    telecommunications    line    costs    by    using    a    single 
communications    line    and    single    work    station    to    access    data 
bases    residing    on   multiple    local    host    computers    as   well    as 
remote    computers. 

*  31.  Acquire  SPLICE  systems  based  on  requirements  to  (a) 
support  current  UADPS-SP  and  (b)  thereafter  to  support  the 
Stock    Point    Replacement    Project. 

32.       Design    SPLICE    as    a    telecommunications    foundation    for 
the    Stock    Point    Replacement    Project    to    permit,    if    required, 
phased    transition    to    the    Replacement    environment. 
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APPENDIX  F 


PROPOSED  SPLICE  PROJECT  STRATEGIES 


I.  INVENTORY  MANAGEMENT 

1.  In  that  Navy  supply  support  will  be  provided  through 
consumer,  intermediate  and  wholesale  echelons,  SPLICE  will 
serve  as  an  horizontal  and  verticle  integration  vehicle 
through  system  wide  telecommunications  capabilities  and 
provide  a  window  to  stock  point  data  and  processes  (where 
security  permits)  to  all  echelons  of  the  NAVSUP  corporation. 
(NSISP  Strategy  4;  SPLICE  Goal  1) 

II.  DATA  MANAGEMENT 

2.  SPLICE  will  support  an  environment  and  monitor  the 
development  of  applications  which  can  provide  data  and  asset 
visibility  so  that  information  is  managed  as  a  NAVSUP 
corporate  resource.   (NSISP  Strategy  5;  SPLICE  Goal  2) 

3.  SPLICE  will  adhere  to  the  NAVSUP  Data  Administration 
program  to  promote  coordinated  and  integrated  policies, 
programs,  and  procedures  to  efficiently  and  effectively 
manage  and  control  corporate  data  and  supporting  resources. 
(NSISP  Strategy  6;  SPLICE  Goal  2) 

4.  SPLICE  will  ensure  that  all  implemented  security 
procedures  are  based  on  economic  risk  analyses  and  will  be 
used  to  protect  information  systems  from  erroneous  denial  of 
services,  or  unauthorized  accidental/intentional 
destruction,  modification,  or  disclosure.   (NSISP  Strategy 
7;  SPLICE  Goal  3) 

5.  SPLICE  information  systems  will  be  designed  to 
electronically  collect,  validate  and  process  data  as  close 
to  the  source  as  possible.   (NSISP  Strategy  8;  SPLICE  Goal 
4) 

III.  SYSTEM  INTEGRATION 

6.  SPLICE  will  emphasize  the  integration  of  logistics, 
business,  and  administrative  information  systems,  through 
the  use  of  standard  SPLICE  minicomputer  hardware  (including 
MAPS  site  replacement),  standard  coding  structures,  commom 
data  elements,  and  common  data  bases  (where  practical). 
(NSISP  Strategy  9;  SPLICE  Goals  1  and  3) 
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7.  SPLICE  will  will  serve  as  the  basis  for  an  economic  and 
comprehensive  long  distance  and  local  telecommunications 
network  using  DDN  or  commercial  facilities,  that  provides 
all  authorized  users,  ashore  and  afloat,  ready  access  to 
logistics  information  in  NAVSUP  data  bases  from  single 
terminals  and  provide  bulk  file  transfer  capabilities,  . 
(NSISP  Strategy  10;  SPLICE  Goals  1,  2,  and  3) 

IV.  SYSTEM  MODERNIZATION 

8.  SPLICE  will  improve  its  effectiveness  and  usefulness  by 
protecting  existing  UADPS-SP  programs  from  obsolescense 
until  SPAR,  providing  stock  point  interactive  capabilties, 
permitting  the  download  of  "functionally  transparent"  and 
site  local  stock  point  applications,  purifying  data  bases, 
acquiring  efficient  hardware,  software,  facilities, 
developing  systems  which  meet  customer  needs,  and  providing 
a  telecommunications  and  office  automation  foundation  for 
the  SPAR  project  to  permit,  if  required,  phased  transition 
to  the  Replacement  environment.   (NSISP  Strategy  11;  SPLICE 
Goal s  1,  2,  and  3) 

9.  All  SPLICE  resident  functional  area  COBOL  applications 
will  be  portable  and  machine  independent  in  order  to 
promote  competition  in  future  information  systems  resource 
acquisitions  and  in  preparation  for  SPAR.   (NSISP  Strategy 
13;  SPLICE  Goal  3) 

10.  SPLICE  will  use  proven,  commercially  available  hardware 
and  software  products,  where  possible,  implemented  in  a 
phased  manner  to  assure  installation  success  and  provide  for 
adequate  test  time.   (NSISP  Strategy  14;  SPLICE  Goal  5) 

VI.  RESOURCE  MANAGEMENT 

11.  All  SPLICE  environmental  and  application  actions  will 
be  initially  justified  by  economic  analyses  and  subsequently 
audited  for  achievement  of  analysis  objectives.   (NSISP 
Strategy  19;  SPLICE  Goal  5) 

12.  SPLICE  will  optimize  the  use  of  its  FMSO  resources  for 
major  standard  information  systems  with  emphasis  on  new 
systems  development.   (NSISP  Strategy  20;  SPLICE  Goal  5) 

13.  SPLICE  project  actions  will  be  documented  and  managed 
through  the  SUP  04  Strategic  and  Tactical  Information 
Systems  Plan  and  will  support  the  NAVSUP  Corporate  Plan  and 
the  Navy  ISSP.   (NSISP  Strategy  21;  SPLICE  Goal  5) 

14.  SPLICE  will  continue  to  apply  Life  Cycle  Management 
procedures  as  the  standard  methodology  for  all  its  programs 
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and    ensure    same    for    supported    projects. 
SPLICE    Goal    5) 


(NSISP    Strategy    22; 


15.  SPLICE    will     improve    the    effectiveness    of    its    hardware, 
software,    and    facilities    through    participation    in    the    NAVSUP 
configuration    and    capacity    management    program,    with 
particular    emphasis    on    ensuring    that    new    UADPS-SP    projects 
do    not    saturate    existing    stock    point    hardware.       (NSISP 
Strategy    23;    SPLICE    Goal    5) 

16.  SPLICE    will    provide    a    customer    charge-back    system, 
through    which    its    c u s tomer s/ u ser s    can   manage    and    control    the 
cost    of   data    processing    services.       (NSISP    Strategy    24; 
SPLICE    Goal    5) 

VII.  TECHNOLOGY  EXPLOITATION 

17.  SPLICE    will    advocate    and    provide    for    state-of-the-art 
technology    in    its    information    system    initiatives.       (NSISP 
Strategy    26;    SPLICE    Goal    7) 

18.  SPLICE    will    provide    technology    refreshment    throughout 
its    life-cycle    through    periodic    site    upgrades,    government    or 
vendor    recommended    component    substitutions,    and    supporting 
budget    strategies.       (NSISP    Strategy    27;    SPLICE    Goal    7) 
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APPENDIX  G 


PROPOSED  SPLICE  PROJECT  OBJECTIVES 


I  INVENTORY  MANAGEMENT 


OBJECTIVE 


SPLICE 
STRATEGY 


(FY/Q) 
TARGET 
DATE 


1.       Implement    sensitivity    and 
trade-off    analysis    ("What    If") 
capabilities    to    answer    material/ 
funds/effectiveness    questions    by 
Stock    Point    item   managers    through 
the    use    of    SPLICE    locally    networked 
microcomputers.       (NSISP    Objective    3,72) 


1,2,5, 
8,10,17 


86/4 


2.   Initiate  the  implementation 
of  the  RIMSTOP  capabilities  through 
SPLICE  at  Navy  Stock  Point  activities 
(NSISP  Objective  5) 


1,2 


91/4 


3.       Identify    the    actions 
required    to    accelerate    the 
implementation    of    the   multi-echelon 
requirements    determination    model 
through    implementation    of    planned 
RIMSTOP    capabilities    on    SPLICE. 
(NSISP    Objective    7) 


1,2 


86/4 


4.   Validate  rules  and  integrate 
models  for  procurement  and  repair 
requirements  determination  at  Stock 
Points  through  APADE.   (NSISP 
Objective  11) 


91/2 
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5.   Develop  and  implement  procedures 
to  minimize  repetitive  buys  of 
nonstandard  of  Stock  Point  retail 
managed  items  through  APADE  and 
provide  greater  asset  visibiliy. 
(NSISP  Objective  12) 


1,2 


88/4 


II  DATA  MANAGEMENT 


6.   Participate  in  the  NAVSUP 

IRM  program.   (NSISP  Objective  14) 


2,6 


86/4 


7.   Participate  in  the  NAVSUP  Data 
Administration  and  Data  Base 
Administration  Programs.   (NSISP 
Obj  ec  t  ive  15) 


86/2 


8.   Provide  SPLICE  input  to  the 
NAVSUPINST  on  contingency  planning 
(NSISP  Objective  16) 


86/3 


9.   Provide  SPLICE  input  to 
the  ADP  security  instruction, 
NAVSUPINST  5510. 6A  based  upon 
FDC's  Security  Access  System. 
(NSISP  Objective  17) 


86/2 


III  SYSTEM  INTEGRATION 


10.  Provide  SPLICE  input  to  the 
NAVSUP  information  architecture 
that  supports  the  NAVSUP  business 
functions.   (NSISP  Objective  19) 


6,3 


86/3 


11.   Provide  input  to  the  NAVSUP 
data  architecture  that  supports 
the  overall  information  architecture 
(NSISP  Objective  11) 
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12.       Based    on    the    NAVSUP    information 
architecture,    develop    SPLICE 
technical     plans,    including    telecom- 
munications,   office    automation,    and 
security    considerations,    that    exploit 
the    technology    available    through 
the    SPLICE    procurement.       (NSISP 
Obj  ective    21 ) 


6,4,8 
15 


87/3 


13.   Develop  a  SPLICE  tactical  plan 
which  provides  interim  but  standard 
office  automation  systems  at  NAVSUP 
field  activities,  exclusive  of  ICPs. 
(NSISP  Objective  22) 


86/4 


14.   Install  a  TANDEM  based  standard 
office  automation  architecture  at 
NAVSUP  field  activities  exclusive  of 
ICPs,  FMSO,  and  NSCs.   (NSISP  Objective 
24) 


6,5,8 


88/2 


15.   Install  a  SPLICE  based  logistics 

telecommunications  network  using 

the  Defense  Data  Network  (DDN) 

as  the  backbone.   (NSISP  Objective  26) 


7,10 


89/4 


16.       Develop    and    implement  a    SPLICE 

based    plan    to    improve    ship  to    shore 

communication    of    logistics  information. 
(NSISP    Objective    28) 


88/1 


17.   Complete  installation  of 
SPLICE  initial  hardware  at  7  sites. 
(NSISP  Objective  30) 


7,8 


86/4 


18.   Complete  installation  of 
SPLICE  upgrade  configurations  at 
8  sites  to  support  application 
implementation.   (NSISP  Objective  31) 


7,8 


86/4 
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19.   Complete  transfer  of 
communications  devices  from 
Burroughs  communication  procesors 
to  SPLICE  communications  subsystems 
at  NAVSUP  Stock  Points. 
(NSISP  Objective  32) 


7,15 


86/4 


20.   Complete  design,  development 
and  testing  of  SPLICE  Phase  II 
(MAPS  support),  and  prototype  at 
7  sites.   (NSISP  Objective  33) 


86/4 


21 .   Repl ace  OLA  PE  7/32s  with 
SPLICE  hardware  at  stock  points  and 
implement  DDA  project  on  same. 
(NSISP  Objective  34) 


87/1 


22.   Complete  development  of  TCP/IP 
protocol  and  service  protocols  for  DON 
on  SPLICE,  and  prototype  at  one  site. 
(NSISP  Objective  35) 


86/2 


23.   Provide  for  SPAR,  ICP 
Resol ic i tat  ion ,  shipboard, 
logistics  system,  and  office 
automation  integration  requirements 
in  all  planned  SPLICE  initiatives. 
(NSISP  Objective  36) 


89/1 


IV    SYSTEM    MODERNIZATION 


24.       Participate    in    the    implementation      8,5,6 
of    the    DOD    In terchangeab il i ty    and  11,12 

Sub sti tutab il i ty    System,    through 
on-line    implementation    of    the    ML-N,    MRIL 
and    MCRL    on    SPLICE.       (NSISP    Objective    37) 


87/1 
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25.   Develop  a  proposal  for 
interfacing  to  an  Information 
Center  at  NAVSUP  HQ.   (NSISP 
Objective  25) 


8,5,6 


86/4 


26.       Complete    installation    of  8,5,6 

Integrated    Disbursing    and  11,12 

Accounting    applications    on 
SPLICE    hardware.       (NSISP    Objective    42) 


88/2 


27.   Prepare  for  implementation  of 
IDA/FMS  and  NAVCIPS  on  NAVCOMPT 
provided  ADPE  and  application 
software,  using  SPLICE 
telecommunications  facilities. 
{NSISP  Objective  43) 


8,5,6 
11,12 


89/4 


28.       Develop    a    TANDEM    based    software 
portability    plan.       (NSISP    Objective    54) 


86/4 


29.   Provide  input  to  the  SPAR 
transition/conversion  plan  for 
SPLICE  resident  applications  and 
tel ecommun  ica t  ions  f ac  il i  t  ies . 
(NSISP  Objective  56) 


9,11,12    86/1 


30.   Assist  in  APADE  Phase  I 
integrated  system  testing,  perform 
sizing  studies,  and  provide  hardware 
interface  and  environmental 
so f tware/ test i ng  support. 
(NSISP  Objective  61) 


8,5,9 


86/2 


31.   Complete  APADE  installations; 
assist  in  APADE  prototype;  tune 
appliction  after  installation. 
(NSISP  Objective  63) 


88/4 
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32.   Assist  in  the  replacement  of 
stock  point  obsolete  peripheral 
equipment,  by  replacing  with  SPLICE 
equipment  where  possible.   (NSISP 
Objective  68) 


87/4 


33.   Eliminate  PCAM  equipment  at 
NSCs  and  other  activities  that  are 
within  NAVSUP  control  through  SPLICE 
OLTP  facilities  and  from  whom  they 
receive  input  through  providing  SPLICE 
telecommunications  interfaces.   (NSISP 
Objective  69) 


91/1 


34.   Incorporate  decision  support 
systems  (downloads  and  micro  based) 
in  SPLICE  that  provide  the  information 
required  for  activity  management  and  HQ 
feedback.   (NSISP  Objective  72) 


89/3 


35,   Develop  and  execute  a 
methodology  to  eliminate  errors  in 
existing  stock  point  data  bases 
through  increased  use  of  OLTP  and 
insure  the  quality  of  new  input. 
(NSISP  Objective  73) 


89/3 


VI  RESOURCE  MANAGEMENT 


36.       Enforce    the    policy    for 
management    of    local    unique 
applications    at    stock    points 
on    SPLICE.       (NSISP    Objective    36) 


11,14 


86/2 


37.       Participate    in    the    NAVSUP 
operational    hardware    and 
environmental     software   management 
program    through    the    SPLICE 
Configuration    Management    System. 
(NSISP    Objective    92) 
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38.   Participate  in  the  NAVSUP 
operational  capacity  management 
program  through  SPLICE  capacity 
expansion,  system  sizing  and 
resource  management  systems. 
(NSISP  Objective  93) 


15 


89/2 


39  .  Imp!  emen  t  a 
system  to  manage 
costs  from  users 
data  centers  and 
(NSISP    Objective 


SPLICE    charge-back 
and/or    r ec  ov  er 
of    stock    po  in t 
networks . 
94) 


16,10 


87/1 


VII    TECHNOLOGY    EXPLOITATIO 


40.       Provide    SPLICE    inputs    to 
the    NAVSUP    emerging    technology 
program.       (NSISP    Objective    96) 


17,18 


86/2 


41.       Using    the    SPLICE    contract 
substitution    clause    and    LCN    interface 
capability,    provide    for    the    infusion 
of    new    and    emerging    technology    into 
NAVSUP    information    systems.       (NSISP 
Objective    97) 


17,18 


86/2 


42.      Provide    SPLICE    related    inputs 
to    the    NAVSUP    technical    reference 
library    on    state-of-the-art 
technology    for    hardware,    software,    and 
system    integration    techniques. 
(NSISP    Objective    98) 


17, 


86/3 
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43.   Implement  SPLICE  ABE  at  8  NAVSUP    1,5,6 
stock  points.  (NSISP  Objectives  31,      8,9,11, 
32,  56,  73)  12 


4/87 


44.       Incorporate    bar    code    technology 
(i.e.,    readers    and    medium    duty    bar    code 
printing    laser    devices)     into    SPLICE    and 
implement    on    applicable    supported 
applications.       (NSISP    Objectives    68,    69, 
73,    97) 


2,5,8, 
10,17,18 


3/86 


45.   Support  the  download  or  SPLICE 
disk  placement  of  additional 
Burroughs  Master  or  tape  files 
(e.g.,  MRIL,  ML-N,  MCRL,  etc.)  for 
inquiry,  stand  alone  processing  and 
source  data  purposes  (NSISP  Objectives 
21,  56,  68,  69,  73) 


2,5, 
7,8 


1/87 


46.   Expedite  the  movement  of  End-of- 
Day  procesing  to  SPLICE,  using  the 
SPLICE  maintained  TRANSRECON. 
(NSISP  Objectives  21,  56,  68,  69,  73) 


1.2,8, 
15 


2/87 


47.   Support  and  expedit  the  transition  2,5,6 
of  NAVADS  to  the  SPLICE  Environment.     7,8,15 
(NSISP  Objectives  21,  31,  56,  68,  69, 
73) 


4/86 


48.   Support  and  expedit  integration  2,5,6 

of  NISTARS  concepts  and  programs  8,9,10 

into  SPLICE.  (NSISP  Objectives  21,  12,15,17 
56,  68,  69,  73,  97) 


4/86 


49.   Support  and  expedit  the  2,5,6 

elimination  of  card  oriented  inventory   8,9,10 
processes  by  transition  of  inventory     12,15,17 
tool  creation  to  SPLICE  using  OLTP. 
(NSISP  Objectives  21,  56,  68,  69,  73, 
and  97) 


4/86 
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50.   Support  the  implementations  and  2,5,6 

enhancements  of  SPLICE  TLOD.  8,9,10 

(NSISP  Objectives  21,  56,  68,  69,  73,  12,15,17 
and  97) 


4/86 
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